Use cases
This section describes the following Pure Storage monitoring use cases:
- Storage Capacity Monitoring and Optimization
- Performance Optimization
- Traffic Management
Storage Capacity Monitoring and Optimization
Making sure that a storage system has enough remaining disk space available is critical for several reasons:
- SAN administrators want to make sure to be able to provision disk space for new servers when requested, as quickly as possible.
- The storage system itself may need additional disk space for specific features to work properly, like automatic snapshots, mirroring, etc.
- If thin provisioning is used, the remaining disk space becomes dramatically critical since the inability to allocate additional space to a LUN when requested by the subscriber host will lead to catastrophic data loss and corruption.
Reporting on Disk Space Consumption
The main SEN_PURE_STORAGESYSTEM application class reports various metrics regarding the disk space in the storage system:
- The size of the storage system (Information available in the InfoBox)
- The total subscribed capacity, i.e. the total amount of disk space exposed to the servers with the SubscribedCapacity parameter
- The total amount of free disk space with the AvailableCapacity parameter.
Detecting Oversubscription Situations (Thin Provisioning)
We call an oversubscription situation when:
- The storage system is configured for thin provisioning (“thin storage pool”)
- The storage system is oversubscribed, i.e. the total disk space visible to the hosts (subscribers) is greater than its actual capacity (this situation is normal for a thin pool since it is its very purpose)
- The storage system actual consumed capacity is higher than 75%
Such situation is highly critical because the inability to allocate additional space to a LUN when requested by the subscriber host will lead to catastrophic data loss and corruption.
The OversubscriptionSituation parameter will alert you of an oversubscription situation by triggering an alarm. When such an alarm is issued by the KM, it is highly recommended that the SAN administrators add capacity as soon as possible.
Reclaiming Space of Unused LUNs
Identifying Unmapped (Orphans) LUNs
Over time, as servers connected to a SAN get decommissioned, administrators find an increasing number of unmapped LUNs, or volumes that are no longer used by any server. These LUNs, while unused, still occupy disk space in the storage system. Being able to identify such unmapped LUNs and reclaim the disk space uselessly consumed by these LUNs will help administrators avoid unnecessary upgrades and extensions of their storage systems.
To list the LUNs in a storage system that are not mapped to any server and therefore safe to remove, right-click the KM main icon or the storage system icon > KM Commands > Reporting > LUNs Mapping Table…
Whether a LUN is actually mapped or not is also shown in the InfoBox of each volume instance.
Identifying Unused LUNs
When a server is decommissioned or reconfigured, its associated LUNs can stay mapped preventing storage administrator from accurately identifying unused LUNs. Since the KM monitors permanently the traffic on each LUN, it becomes easy to detect LUNs for which the activity is null.
-
Create a PATROL Query in the PATROL Console to show the value of the TimeSinceLastActivity parameter of the SEN_PURE_VOLUME application class; In the main menu bar, click Action > New Query…
-
Enter the Query name (example: Unused LUNs)
- Enter the Query description (optional)
- In the Query Results Filter section, select Show Selected Objects and check the Parameters box
- In the Additional Filtering, select the Application Class level filtering and the Enable Parameter level filtering options
- Open the Application Class tab
-
In the Pattern Matching section, select Like and type SEN_PURE_VOLUME
- Open the Parameter tab
-
In the Pattern Matching section, select Like and type TimeSinceLastActivity
- Click OK to display a list of the monitored LUNs and their respective number of days since when the KM has not recorded any activity.
The value collected for this parameter upon the first collect reflects the number of days since any activity occurred on the volume for the time observed by the KM, i.e. this first collected metric might not reflect the actual absence of activity on the volume.
Performance Optimization
Diagnosing Slow LUNs
If a system administrator complains that his servers are experiencing slow I/Os performance and that it is caused by the SAN, you may want to verify the actual response time of the LUNs the server is relying on.
The ResponseTime parameter of the SEN_PURE_VOLUME application class represents the average time it took to complete the read and write operations on the LUN during the collection interval. Typically, the average response time is below 10 milliseconds. You may also want to compare this value to the response time of the other LUNs to see whether one server is really getting worse I/O performance than another.
Traffic Management
Identifying Busiest LUNs
To identify the LUNs that generate the most traffic on the disk array, you can use the ReadByteRate and WriteByteRate parameters of the SEN_UNITY_VOLUME class. Pure Storage KM for PATROL offers you two methods to visually represent a LUN traffic:
Method 1: Creating a Multi-Parameter Graph
- In the PATROL console, double-click the ReadByteRate parameter of the LUN you are interested in. A graph is automatically displayed in the graph pane.
- Then drag and drop the WriteByteRate parameter in the graph window
Method 2: Using the Volume Activity… Command
- Right-click the Volume for which you want to create a daily or hourly report of the total amount of data in GB that was read off or written to the each LUN, and select Volume Activity…
- Define the report settings:
- Select the data for which you wish to generate a report for: read bytes traffic, write bytes traffic, transfer bytes traffic or read/write bytes
- Select the period that you wish the report to cover: number of days or hours
- Select the interval to apply to the report data: hourly or daily
- Click the Show Report button to display the graph.
Reporting the Total Traffic on an Hourly or Daily Basis
Pure Storage KM for PATROL not only monitors the traffic and activity of the storage system and volumes in MB/sec, but also in GB per hour or per day. The exact amount of data that was read or written to the storage system and volumes is calculated for each hour of the day and each day of the week.
The hourly report graph will represent the amount of data in GB from 12:00am to 12:59am, from 1:00am to 1:59am, from 2:00am to 2:59am, etc, while the daily report graph will represent the amount of data in GB for Monday, for Tuesday, for Wednesday, etc.
This report is notably helpful to SAN administrators to understand the impact of the nightly backups, of the amount of data a specific application writes to a volume and how this evolves (with upgrades for example). In general, this will help administrators analyze the impact of various features of the storage system on the long term.
Generating a Storage System Activity Report
-
In the PATROL console, right-click the KM main icon> KM Commands > Reporting > Storage Systems Activity…
-
Define the report settings
- Select the data you wish to generate a report for: read bytes traffic, transfer bytes traffic, write bytes traffic, or read/write bytes
- Select the period that you wish the report to cover: number of days or hours
- Select the interval to apply to the report data: hourly or daily
- Press the Storage System Selection button and select the specific storage system(s) you wish to include in the report
- Click the Show Report button to display the graph.
The ability of the product to report on a given period of time depends on the history retention period of the PATROL Agent.
storage pure km patrol