HP P2000 Controller Test

The storage controller is essentially a server that’s responsible for performing a wide range of functions for the storage system. Each controller has an I/O path to communicate to the storage network or the directly-attached servers, an I/O path that communicates to the attached storage devices or shelves of devices, and a processor that handles the movement of data as well as other data-related functions, such as RAID and volume management. In the modern data center, the performance of the storage system can be directly impacted (and in many cases determined) by the speed and capabilities of the storage controller. If the controller or its processor is unable to meet the I/O processing demands of the infrastructure they support, then slowdowns will become a norm, and user complaints will become routine. Under such circumstances, IT administrators will seriously consider switching to alternative storage solutions with more robust controllers and high processing power. To avoid this eventuality, administrators need to keep checking on overall controller performance and processor usage from time to time, so that they can spot a potential I/O overload condition or a processing delay or a CPU contention before user experience is affected, and fine-tune cache usage, processor capacity, and/or the load-balancing algorithm of the controller to ensure peak performance of the storage system at all times. The HP P2000 Controller test helps administrators in this regard.  

This test auto-discovers the controllers of the HP P2000 SAN storage system, monitors the I/O processing ability of each controller, and reveals the following:

  • Is any controller hogging its CPU? If so, which one is it?
  • Which controller is slow in processing I/O requests? What type of requests are being serviced slowly by that controller – read requests or write requests?
  • How is the cache usage of the slow controller? Is the cache being utilized optimally, or are too many read-write requests serviced by direct disk accesses?

The answers to these questions indicate how healthy each controller is and provide pointers to right-size the processor and controller cache (if needed).

Target of the test : A HP P2000 SAN storage system

Agent deploying the test : A remote agent

Outputs of the test : One set of results for every controller of the HP P2000 storage system being monitored

Configurable parameters for the test
Parameter Description

Test period

How often should the test be executed .

Host

The host for which the test is to be configured. Since the storage device is managed using the IP address of its storage controller, the same will be displayed as host. In case of a dual-controller configuration, the IP address of the primary controller will be displayed here.

Port

The port number at which the specified host listens. By default, this is NULL.

Additional Controller IP

By default, this test always connects to the Host to collect metrics. If the Host is unavailable, then the test will not be able to execute. This is because, the Additional Controller IP is set to none by default.

If the monitored storage device has two controllers, then you can configure the test to connect to an alternate controller, if the host is unreachable. For this purpose, specify the IP address of the alternate controller in the Additional Controller IP text box.

User and Password

In order to monitor a HP P2000 SAN storage system, the eG agent has to be configured with the credentials of a user who has been assigned the Monitor role. Specify the login credentials of such a user in the User and Password text boxes. To know how to create such a user, refer to Pre-requisites for monitoring the HP P2000 SAN storage system.

Confirm Password

Confirm the password by retyping it here.

ServidePort

The Management Controller of the HP P2000 storage system provides access for monitoring and management via the HTTP and HTTPS protocols for XML API request/response semantics. To enable the eG agent to access the management controller, invoke the XML API commands, and collect the required metrics, you need to specify the service port on the controller that listens for HTTP/HTTPS requests for XML API semantics. By default, this is port 80.

Timeout

Specify the time duration for which this test should wait for a response from the storage system in the Timeout text box. By default, this is 60 seconds.

SSL

By default, HP P2000 SAN system is not SSL-enabled. This is why, this flag is set to False by default. If it is SSL-enabled, then change this flag to True.

Measurements made by the test
Measurement Description Measurement Unit Interpretation

CPU busy

Indicates the percentage of time the processor on this controller was busy processing requests.

Percent

A value close to 100 is a cause of concern.

Comparing the value of this measure across controllers will enable you to accurately identify the controller whose CPU resources are consumed excessively. If the value of this measure remains high for that controller, it is an indication that the processor is getting choked and may require more processing power. This would also indicate an I/O overload. In this case, you may want to tweak the load-balancing algorithm of the storage system to reduce the load on a single controller and to optimize CPU usage.

Data transmitted

Indicates the rate at which data was transmitted by this controller during the last measurement period.

MB/sec

This is a good indicator of the load on the controller. You can compare the value of this measure across controllers to figure out whether the load has been distributed uniformly across all controllers or a few controllers are overloaded. In case of the latter, you may have to fine-tune the load-balancing algorithm used.

IOPS

Indicates the rate at which the I/O operations were performed by this controller during the last measurement period.

IOPS

This measure serves as a good indicator of the I/O processing ability of the controller. A consistent drop in this value is hence a cause for concern, as it indicates a processing slowdown.

Reads

Indicates the rate at which the read operations were performed on this controller during the last measurement period.

Reads/Sec

Ideally, the value of this measure should be high. A steady dip in this measure value could indicate a potential reading bottleneck. Under such circumstances, you may want to check the value of the Read cache hits and Read cache misses measure to figure out whether under-utilization of the cache is the cause for the reading delay. 

Read cache hits

Indicates the rate at which the blocks were read from the cache instead of the volumes held by this controller.

Hits/Sec

Ideally, the value of the Read cache hits measure should be high, and the value of the Read cache misses measure should be low. A consistent drop in cache hits and a steady increase in cache misses during the same time frame is indicative of ineffective read cache usage, which can lead to a slowness in read request servicing. To improve read cache usage, you may want to consider turning on read-ahead caching. You can optimize a volume for sequential reads or streaming data by changing its read-ahead cache settings. Read ahead is triggered by two back-to-back accesses to consecutive LBA ranges, whether forward (increasing LBAs) or reverse (decreasing LBAs).

You can change the amount of data read in advance after two back-to-back reads are made. Increasing the read-ahead cache size can greatly improve performance for multiple sequential read streams; however, increasing read-ahead size will likely decrease random read performance.

  • The Default option works well for most applications: it sets one chunk for the first access in a sequential read and one stripe for all subsequent accesses. The size of the chunk is based on the chunk size used when you created the vdisk (the default is 64 KB). Non-RAID and RAID-1 vdisks are considered to have a stripe size of 64 KB.
  • Specific size options let you select an amount of data for all accesses.
  • The Maximum option lets the controller dynamically calculate the maximum read-ahead cache size for the volume. For example, if a single volume exists, this setting enables the controller to use nearly half the memory for read-ahead cache. Only use Maximum when disk latencies must be absorbed by cache. For example, for read-intensive applications, you will want data that is most often read to be in cache so that the response to the read request is very fast; otherwise, the controller has to locate which disks the data is on, move it up to cache, and then send it to the host.

Read cache misses

Indicates the rate at which the read requests to the volume of this controller were not serviced by the read cache.

Misses/Sec

Writes

Indicates the rate at which the write operations were performed on this controller during the last measurement period.

Writes/Sec

Ideally, the value of this measure should be high. A steady dip in this measure value could indicate a potential writing bottleneck. Under such circumstances, you may want to check the value of the Write cache hits and Write cache misses measures to figure out whether under-utilization of the cache is the cause for the writing delay. 

Write cache hits

Indicates the rate at which the write requests to the volume of this controller were fulfilled by the write cache.

Hits/Sec

Ideally, the value of the Write cache hits measure should be high, and the value of the Write cache misses measure should be low. A consistent drop in cache hits and a steady increase in cache misses during the same time frame is indicative of ineffective read cache usage, which can lead to a slowness in write request servicing. To improve write cache usage, you may want to consider changing that volume’s write-back cache setting. Write-back is a cache-writing strategy in which the controller receives the data to be written to disks, stores it in the memory buffer, and immediately sends the host operating system a signal that the write operation is complete, without waiting until the data is actually written to the disk. Write-back cache mirrors all of the data from one controller module cache to the other. Write-back cache improves the performance of write operations and the throughput of the controller.

Write cache misses

Indicates the rate at which the write requests to the volume of this controller were not serviced by the write cache.

Misses/Sec

Data reads

Indicates the rate at which the data was read from this controller during the last measurement period.

MB/Sec

Comparing the value of these measures across the controllers will clearly indicate which controller is the busiest in terms of the rate at which data is read and written - it could also shed light on irregularities in load balancing across the controllers.

Data writes

Indicates the rate at which the data was written from this controller during the last measurement period.

MB/Sec