EMC PowerVault ME 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 EMC PowerVault ME Controller test helps administrators in this regard.
This test auto-discovers the controllers of the EMC PowerVault ME 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 EMC PowerVault ME storage system
Agent deploying the test : A remote agent
Outputs of the test : One set of results for every controller of the EMC PowerVault ME storage system being monitored
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 EMC PowerVault ME 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 EMC PowerVault ME storage system. |
Confirm Password |
Confirm the password by retyping it here. |
ServicePort |
The Management Controller of the EMC PowerVault ME 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, EMC PowerVault ME 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. |
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.
|
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 |