Storage Tier Reports - · PDF fileStorage tier reports help users to engage in capability...

IBM Tivoli Storage Productivity CenterVersion 4.2.2

Storage Tier Reports

Authors:Mike LambPatrick LeahyBalwant RaiJackson Shea

ContentsIntroduction.....................................................................................................................................3

Knowledge and skills prerequisites............................................................................................3

Important concepts....................................................................................................................3

Storage virtualizers...............................................................................................................3

Capacity versus capability....................................................................................................3

Tiering...................................................................................................................................4

Up-tiering and down-tiering...................................................................................................4

MDisk group characteristics...........................................................................................................4

General theory of capability calculation.....................................................................................4

Using a SQL query to retrieve back-end configuration data.......................................................6

Grouping similarly performing MDisks.......................................................................................6

Complexity of modeling XIV systems with isolated workloads...................................................8

Easy Tier, Storage Optimizer, and storage tier reports............................................................10

Use case: Identifying MDisk groups for up-tiering or down-tiering................................................10

Description...............................................................................................................................10

Analyzing storage tier reports..................................................................................................11

Steps for analyzing MDisk groups.......................................................................................12

Steps for analyzing VDisks.................................................................................................13

Case study...............................................................................................................................16

Analyzing the deletepool2 MDisk group for up-tiering.........................................................16

Analyzing the cognos MDisk group for up-tiering................................................................17

Analyzing the mdiskgrp1 MDisk group for down-tiering......................................................19

Analyzing the deletemdiskgrp3 MDisk group for down-tiering............................................20

Identifying most active VDisks to reduce MDisk group workload........................................21

Using storage resource groups to analyze application performance...................................23

Scheduling reports........................................................................................................................26

Sending reports by email.........................................................................................................27

Creating a report view..............................................................................................................27

Locating related documentation..........................................................................................29

Appendix 1: SQL query for retrieving back-end data...............................................................31

Storage Tier Reports page 2 of 33

IntroductionThe inclusion of storage tier reports in IBM® Tivoli® Storage Productivity Center Version 4.2.2 helps users by providing them with quantitative data to make important decisions about storage tiering. By leveraging estimated capability and actual performance data for IBM System Storage® SAN Volume Controller and IBM Storwize® V7000, storage tier reports help answer important storage management questions such as:

● Is a back-end subsystem being utilized to its fullest capability

● Can a workload be moved to a lower cost pool of storage while still meeting service level agreements

● How to level out performance in a pool to meet service level agreements

The purpose of the white paper is to help users:

● Define the characteristics of managed disk (MDisk) groups so as to provide an accurate model of the theoretical capability of MDisk groups

● Use storage tier reports to make storage management decisions

● Schedule storage tier reports

Knowledge and skills prerequisitesIt is expected that users are:

● Familiar with back-end storage subsystem architecture and RAID concepts

● Familiar with the Tivoli Storage Productivity Center GUI and performance reporting

● Familiar with and know how to execute SQL queries in IBM DB2® using either the command line interface (CLI) or the Control Center (GUI)

Important conceptsStorage virtualizers

In this white paper, the term storage virtualizer is used to refer to SAN Volume Controller and Storwize V7000 storage systems.

Capacity versus capabilityCapability is the term that is used to refer to performance, whereas capacity is the term that is used to refer to space. Storage tier reports help users to engage in capability planning to ensure that existing and future workloads meet or exceed the service level agreements that govern the interaction between storage and applications. Traditionally, users have focused on capacity planning to ensure that they have sufficient space for existing and future applications.


Tiering Tiering is the term that is used to describe storage systems that comprise different performing subsystems, or physical disks within a subsystem that have different price points. The subsystems and physical disks are organized into different MDisk groups in storage virtualizers.

Up-tiering and down-tieringUp-tiering and down-tiering are the terms that are used to refer to the process of moving a virtual disk (VDisk) from one type of MDisk group to another MDisk group. Up-tiering refers to a movement from a lower capability pool to a higher capability pool. Usually, this means going from a lower cost pool to a higher cost pool, but that is not always the case.

Down-tiering refers to the movement of a workload from a higher capability pool to a lower capability pool. Usually, this means going from a higher cost pool to a lower cost pool, but again, this is not always the case.

MDisk group characteristicsGeneral theory of capability calculation

Storage tier reports produce value as an analytics tool by comparing actual I/O performance metrics with the theoretical capability of a particular MDisk group. To do this, users must provide some of the characteristics of the back-end pool that make up the MDisk group so that the theoretical capability of the MDisk group can be calculated. The characteristics of the back-end pool that are required are:

● The type of storage system

● The type of RAID

● The size and rotation speed of physical disks

● The number of physical disks

The formula that is used in Tivoli Storage Productivity Center to calculate estimated I/O capability assumes a 70/30 read/write workload split and multiplies the number of spindles in an MDisk group by the theoretical capability of each spindle based on the disk technology and rotation speed. RAID type and cache hit ratio values, based on the type of subsystem, is also factored into the I/O per second rate that is used as the theoretical maximum for the MDisk group. (For more information about the read I/O capability formula, see Locating related documentation.)

To set the characteristics of a back-end pool using the Tivoli Storage Productivity Center, GUI, expand Disk Manager and Storage Subsystems, select a SAN Volume Controller or Storwize V7000 storage subsystem, and click the MDisk Groups button. (See Illustration 1.)


Illustration 1: Selecting a storage subsystem

A list of MDisk groups for the selected subsystem is displayed. When you select an MDisk group, the details panel for the MDisk group is displayed. The characteristics of the back-end pool are set in the Information About the Backend Subsystem Pool section (see Illustration 2).

Illustration 2: MDisk group back-end pool characteristics

If you select a Storwize V7000 with internal disks, the back-end pool characteristics are automatically set (see Illustration 3).


Illustration 3: Storwize V7000 with internal disks

Selecting values1 from the drop-down lists is straightforward with the exception perhaps of specifying the number of physical disks in the back-end pool. It is not always easy to specify how many physical disks make up the MDisks that are presented to a storage virtualizer.

Using a SQL query to retrieve back-end configuration dataThe code (see Appendix 1: SQL query for retrieving back-end data) can be used to produce a table of all SAN Volume Controller or Storwize V7000 MDisk groups in the Tivoli Storage Productivity Center database where each row displays the RAID level and back-end physical disk count for a single MDisk in an MDisk group (see Illustration 4)2.

Note: You must probe back-end storage subsystems in order for the SQL query to provide the results. Spare devices are taken into account only on IBM DS6000® and IBM DS8000® series.

Illustration 4: Sample output from a back-end SQL query

The following section provides some best practice guidelines about creating MDisks on DS8000 and the IBM XIV® Storage System and organizing MDisk groups on a back-end array.

Grouping similarly performing MDisksIn order to maximize predictability and consistency in performance for extents that are randomly distributed throughout an MDisk group, it is important that all of the MDisks in a

1 The constants for the drop-down items, such as the cache-hit ratio for a subsystem type or the I/Os per second of a specific type of physical disk can be customized using the Tivoli Storage Productivity Center CLI (see Locating related documentation).

2 The table that the query produces lists DS6K or DS8K disk totals in one column, and non-DS6K or DS8K disk totals in a separate column.


group have identical performance characteristics3. While this is true as a general rule, it becomes more important in the context of storage tier reports which models the theoretical capability of an MDisk group based on the characteristics of a single type of disk and RAID configuration.

To illustrate this, consider a typical DS8000 array and the best practice recommendation for presenting volumes as MDisks to be used on a storage virtualizer (see Illustration 5). Starting with a two frame IBM DS8700® with 300 GB 15,000 rpm drives which are configured with RAID 5 protection, 48 8-disk array sites are created, half of which contain a spare drive (6 + P + S)4 and half which do not (7 + P). Because storage virtualizers distribute extents across the presented volumes, we organize each 8-disk array site into a RAID group or rank, which in turn, is placed in its own extent pool from which a single fixed block volume would be constructed for presentation to the storage virtualizer.

Illustration 5: Two-frame DS8700 with volume overlay

3 IBM Easy Tier™ MDisk groups are an exception to the rule because Easy Tier employs autonomic hot spot relocation between solid state drives (SSDs) and hard disk drives (HDDs) within an MDisk group (see Easy Tier, Storage Optimizer, and storage tier reports).

4 6 + Parity + Spare versus 7 + Parity are RAID descriptions of how 8-disk RAID sets are designated.


In this scenario, 24 1844 GB volumes and 24 1582 GB volumes are created. On storage virtualizers, it is best practice to group the 1844 GB into one or more MDisk groups and the 24 1582 GB into one or more MDisk groups depending on whether application isolation requires subdivision of your storage resources. We isolate the 6 + P + S volumes from the 7 + P volumes because they possess slightly different performance characteristics, with the 7 + P volumes having access to a slightly higher physical disk count. If no application isolation is required, then the simplest scenario would be two MDisk groups, one for the 6 +P + S (1582 GB) volumes and one for the 7 + P (1844 GB) volumes. We will refer to the 7 + P MDisk group as the Long group and the 6 + P + S as the Short group.

The Long group would contain 24 x 8 or 192 physical disks and the Short group would contain 24 x 7 or 168 physical disks.

Complexity of modeling XIV systems with isolated workloadsAs mentioned in the previous section describing a simple configuration, workload isolation may lead to the creation of multiple MDisk groups. Furthermore, the recommended way to isolate workloads is to first subdivide the MDisks into functional groups, such as those that are 6 + P + S versus those that are 7 + P on different ranks, on the back-end subsystem and then group them into MDisk groups on the storage virtualizer. In our example, we had Long volumes and Short volumes, each of which were localized to pools drawn from a particular 8-Disk Array Site and Rank.

The highly virtualized and autonomically optimized architecture of XIV systems complicates this physical isolation. In a simple scenario, (see Illustration 5), an entire XIV system is provisioned into 45 (1 TB disks) 1520 GB5 volumes which are all provisioned to the storage virtualizer and put in a single MDisk group. The MDisk group has 180 physical disks in a fully configured XIV system frame. Each MDisk group contains 15 out of the 45 MDisks, or one third of the 180 physical disks. Hence, we would specify that each MDisk group has 60 physical disks.

5 The XIV system uses decimal capacity specification whereas storage virtualizers use binary capacity specification, so a 1632 decimal GB volume on the XIV system will end up being a 1520 binary GB volume on a storage virtualizer. Using 1 TB physical disks, a fully configured XIV system produces 45 x 1520 GB storage virtualizer, double that for 2 TB physical disks.


MDISKGROUP:XIV1_0

MDISK:XIV1_LV35

MDISK:XIV1_LV00MDISK:XIV1_LV01MDISK:XIV1_LV02

LV441632GB

SVC

...LV001632GB

...

XIV11TB 7500rpm

Illustration 6: Single MDisk group per subsystem

However, if workload or departmental isolation leads a storage administrator to subdivide the XIV system capacity into multiple MDisk groups on a storage virtualizer, then that greatly complicates how we model the performance of that MDisk group. Each MDisk has access to all 180 physical disks. As long as all of the MDisks are in the same MDisk group, there is no issue. If we put MDisks from the same XIV system into different MDisk groups, and if we specify 180 physical disks for each of those MDisk groups, then we end up over representing the I/O capability of our environment. The simple solution to this is to arbitrarily prorate or scale the capability in accordance with the capacity of the MDisk group. While this may lead to more threshold breaches where actual measured I/Os per second exceed the theoretical capability, this conservative approach will guard against overestimating the amount of capability in an MDisk group, and more importantly, in the overall environment.

For example, suppose a single XIV system fully configured with 1 TB physical disks is broken into three equal MDisk groups with the following names:

● Finance

● Marketing

● Customer_Service6

Each MDisk group contains 15 x 1520 GB MDisks, or one third of the 180 physical disks, so we would specify that each MDisk group has 60 physical disks.

6 MDisk group names cannot contain blank spaces


Easy Tier, Storage Optimizer, and storage tier reportsIBM Easy Tier™ is an autonomic capability in a storage virtualizer that relocates highly utilized extents within an MDisk group to MDisks defined as being in a higher performing tier within that MDisk group, and relocates it to the lower performing tier once the extents become less utilized. The Easy Tier functionality in storage virtualizers deals with two tiers: SSDs and HDDs. Relocation occurs automatically and is not configurable.

Storage Optimizer is an analytics and prescriptive function within Tivoli Storage Productivity Center introduced in version 4.1 that produces a heat map of MDisk groups by comparing actual I/O measurements against Disk Magic for IBM7 data based estimations for the particular IBM back-end subsystem. The heat map produced displays color-coded levels of utilization at the MDisk group level. Furthermore, you can specify source and target MDisk groups and request Storage Optimizer to propose VDisk migrations that would level out the performance, and present you with modeled results.

While this is similar to storage tier report functionality, there are some key differences.

Storage tier reports is also an analytics tool that compares actual I/O rates with theoretical capability. It differentiates itself from Storage Optimizer by providing the following key functionality:

• User configurable parameters for customized modeling

• Modeling for non-IBM subsystems

• Additional detailed performance information to inform tiering decisions

Use case: Identifying MDisk groups for up-tiering or down-tiering

DescriptionThe use case describes how users analyze the storage workloads of MDisk groups to determine whether they can be migrated to other MDisk groups in a storage virtualizer. It also shows users how to identify a target MDisk group based on current utilization values that is capable of hosting the workload and performing the actual migration.

7 Disk Magic for IBM is a storage subsystem modeling tool licensed by IBM and customized for use with IBM storage. For more information, see http://www.intellimagic.net/intellimagic/products/disk-magic-for-ibm.


http://www.intellimagic.net/intellimagic/products/disk-magic-for-ibm

Analyzing storage tier reports

The starting point of the analysis procedure is the MDisk Groups - Workload Activity Report which provides charts for the most active (and least active) MDisk groups. The specific metrics for capacity and capability are then evaluated to determine whether further investigation is required. If this is the case, then response times are investigated. If it is determined that an MDisk group requires re-balancing, then the VDisk report for the MDisk group is opened. (To open the VDisk report for an MDisk group, click the bar in the chart that represents the VDisk or click the name of the MDisk group in the report.) In the VDisk report, VDisk candidates for relocation are identified (see Illustration 7 above).


Illustration 7: Use case workflow

Steps for analyzing MDisk groups1. Use the most active or least active MDisk group chart to select an MDisk group that

may require up-tiering or down-tiering.

2. Analyze the values in the following columns in the MDisk group workload report to determine whether up-tiering or down-tiering is required:

Step Column Name Description Comment

Step 1 MDisk Group Read I/O Rate Capability

The read I/O capability rate of the MDisk group in operations per second.

The read I/O capability rate is at the core of storage tier reports. It is the theoretical capability of an MDisk group against which the actual report data is compared.

MDisk group workload is considered to be most active when available capacity is high, and capability is highly utilized.

MDisk group workload is considered to be least active when consumed capacity is high and capability is under utilized.

MDisk Group Max Read I/O Rate

The maximum read I/O rate of the MDisk group in operations per second.

MDisk Group Read I/O Rate Availability

The difference between the read I/O capability rate and the maximum read I/O rate in operations per second.

Step 2 MDisk Group Capacity Status

If the storage capacity that is allocated is less than the actual storage capacity, a status value of OK is displayed. If the storage capacity that is allocated is more than the actual storage capacity, a status value of Warning is displayed. The actual capacity of the MDisk group is calculated as follows:MDisk Group Real Capacity (GB) ÷ MDisk Group Capacity × 100)

MDisk group workload is considered to be most active when capacity is highly available and capability is highly utilized.

MDisk group workload is considered to be least active when when the rate of consumed capacity is high and capability is under utilized.

MDisk Group Capacity The total storage capacity in GB of all of the disks in the MDisk group.

MDisk Group Real The total amount in GB of real


Step Column Name Description Comment

Capacity storage capacity in the MDisk group.

MDisk Group Free Space

The total amount of remaining capacity in GB that can be allocated to increase the size of an existing VDisk, or allocated to an additional VDisk.

Step 3 MDisk Group Max Read Response Time

The maximum read response time in milliseconds per operation.

MDisk group workload is considered to be most active when the maximum read response time is high.

MDisk group workload is considered to be most active when the number of hours and minutes that exceed the threshold is high.

MDisk group workload is considered to be most active when the average read response time is high.

MDisk group workload is considered to be most active when the maximum response time is high.

MDisk group workload is considered to be most active when the number of hours and minutes that exceed the threshold is high.

MDisk Group Max8 Read Response Time Threshold

The number of hours and minutes that the maximum read response time threshold is exceeded over a 24 hour period.

MDisk Group9 Average Read Response Time

The average read response time in milliseconds per operation.

MDisk Group Max Write Response Time

The maximum write response time in milliseconds per operation.

MDisk Group Max Write Response Time Threshold

The number of hours and minutes that the maximum write response time threshold is exceeded over a 24 hour period.

Steps for analyzing VDisksThe procedure that is used to make decisions whether to migrate VDisks is as follows:

8 The Read Response Time Threshold is set to 100% in the sample reports. This was done for testing purposes. The default value is 70%.

9 You will notice that the Write Response Time threshold is set to 1% in the sample reports. This was customized for testing. The default value is 70%.


1. Use the most active or least active VDisk chart to select a VDisk .

2. Analyze the values in the following columns in the VDisk report to determine whether a VDisk should be migrated:

Steps Column Name Description Comment

Step 1 VDisk Peak Utilization The highest value of VDisk utilization over a 24-hour period.

VDisk workload is considered to be most active when the peak utilization is high.

Step 2 VDisk Max Read I/O Rate

The maximum read I/O rate of the VDisk in operations per second.

VDisk workload is considered to be most active when the maximum read I/O rate is high.

VDisk workload is considered to be most active when the rate of I/O share of total VDisk read I/O is high and the capacity share of total VDisk capacity is low.

VDisk I/O Rate Share of Total VDisk Read I/O

The maximum read I/O rate of the VDisk as a percentage of the total

maximum read I/O rate of all the VDisks in the MDisk group.

Step 3 VDisk Max Read Response Time

The maximum read response time in milliseconds per operation.

VDisk workload is considered to be most active when the maximum read response time and the number of hours and minutes that the maximum read response time threshold is exceeded are high.

VDisk workload is considered to be most active when the maximum write response time and the number of hours and minutes that the maximum write response time threshold is exceeded are high.

VDisk Max Read Response Time Threshold

The number of hours and minutes that the maximum read response time threshold for the VDisk is exceeded over a 24 hour period.

VDisk Max Write Response Time

The maximum write response time in milliseconds per operation.

VDisk Max Write Response Time Threshold

The number of hours and minutes that the maximum write response


Steps Column Name Description Comment

time threshold for the VDisk is exceeded over a 24 hour period.

Step 4 VDisk Max Read Cache Hits

The maximum read cache hits in percent.

VDisk workload is considered to be most active when the maximum read cache hits and the number of hours and minutes that the maximum read cache hits time threshold is exceeded are high.

VDisk Max Read Cache Hits Time Threshold

The number of hours and minutes that the maximum read cache hits time threshold is exceeded over a 24 hour period.


Case study

Analyzing the deletepool2 MDisk group for up-tiering

You use the most active MDisk groups chart to identify MDisk groups that may require up-tiering. In this use case, the MDisk group deletepool2 is analyzed further to determine whether it is a suitable candidate for up-tiering.


Step Parameters used to determine tiering

Observation Up-tiering recommended

1 MDisk Group Read I/O Rate Capability, MDisk Group Max Read I/O Rate, and MDisk Group Read I/O Rate Availability

The maximum read I/O rate is high compared with capability, and read I/O rate availability is negative.

Yes

2 MDisk Group Capacity Status, MDisk Group Capacity, MDisk Group Real Capacity, and MDisk Group Free Space

The capacity status is OK. In fact, very little capacity is being consumed. Capability, on the other hand, is extremely over-utilized (the actual I/O rate maximum is over 25 times that of the theoretical capability).

Yes

3 MDisk Group Max Read Response Time, MDisk Group Max Read Response Time Threshold, MDisk Group Average Read Response Time, MDisk Group Max Write Response Time, and MDisk Group Max Write Response Time Threshold

Maximum and average read response times are high.

Maximum and average write response times are high. The number of hours that the write response time exceeds the threshold is too high.

Yes

Final recommendation MDisk Group deletepool2 is over-utilized and some of the workloads in this MDisk Group are strongly recommended for up-tiering.

Analyzing the cognos MDisk group for up-tiering




1 MDisk Group Read I/O Rate Capability, MDisk Group Max Read I/O Rate, MDisk Group Read I/O Rate Availability

The maximum read I/O rate varies from less than 10% in one instance, to 20% in another instance. So, the availability rate of the MDisk group fluctuates between 80% to 90%.

No

2 MDisk Group Capacity Status, MDisk Group Capacity, MDisk Group Real Capacity, MDisk Group Free Space

The capacity status is set to Warning.

Consumed capacity is high (79.90 GB), and capability utilization is low fluctuating between 10% and 20%.

No

3 MDisk Group Max Read Response Time, MDisk Group Max Read Response Time Threshold, MDisk Group Average Read Response Time, MDisk Group Max Write Response Time, and MDisk Group Max Write Response Time Threshold

Maximum and average read response times are high.

Maximum and average write response times are high, and the number of hours that the write response exceeds the threshold is too high.

No

Final Recommendation: MDisk Group cognos is not over-utilized and its workloads are not recommended for up-tiering.


Analyzing the mdiskgrp1 MDisk group for down-tiering


Observation Down-tiering recommended


The availability rate is very high. Yes


The capacity status is set to Warning. Capacity utilization is also high.

Yes

3 MDisk Group Max Read Response Time, MDisk Group Max Read Response Time Threshold, MDisk Group Average Read Response Time, MDisk Group Max Write Response Time, MDisk Group Max Write Response Time Threshold

Maximum and average read response times are very low.

Maximum and average write response times are OK and the number of hours that the write response exceeds the threshold is too high.

Yes

Final Recommendation: MDisk Group mdiskgrp1 is under-utilized and its workloads are strongly recommended for down-tiering.


Analyzing the deletemdiskgrp3 MDisk group for down-tiering


Observation Down-tiering recommended


Availability is high. Yes


The capacity status is set to OK, but there is little free space.

Yes

3 MDisk Group Max Read Response Time, MDisk Group Max Read Response Time Threshold, MDisk Group Average Read Response Time, MDisk Group Max Write Response Time, MDisk Group Max Write Response Time Threshold

Response times are reasonable. Yes

Final Recommendation: MDisk Group deletemdiskgrp3 is under utilized and its workloads are recommended for down-tiering.


Identifying most active VDisks to reduce MDisk group workload

Analyzing the tvt VDiskThe most active VDisk in the MDisk group is tvt. Complete the steps in the following table to determine whether the VDisk requires up-tiering or down-tiering.



1 VDisk Peak Utilization VDisk peak utilization is high. Yes

2 VDisk Max Read I/O Rate, VDisk I/O Rate Share of Total

VDisk Max Read I/O Rate is very high. VDisk I/O Rate

Yes




VDisk Read I/O share of Total Vdisk read I/O Rate is high and VDisk capacity share of total VDisk Capacity is low.

3 VDisk Max Read Response Time, VDisk Max Read Response Time Threshold, VDisk Max Write Response Time, and VDisk Max Write Response Time Threshold

Read and write response times are high and the number of hours that the read and write response time thresholds are exceeded are high.

Yes

4 VDisk Max Read Cache Hits and VDisk Max Read Cache Hits Time Threshold

The maximum read cache hits and the number of hours that the maximum read cache hit threshold is exceeded is high.

Yes

Final Recommendation Migrating the VDisk tvt to another MDisk group with adequate capacity would reduce the MDisk group utilization. It will cool off the Mdisk group.

Analyzing the tpcblade4_10 VDiskThe second most active VDisk in the MDisk group is tpcblade4_10. Complete the steps in the following table to determine whether the VDisk requires up-tiering or down-tiering.




1 VDisk Peak Utilization VDisk peak utilization is low.

Yes

2 VDisk Max Read I/O Rate, VDisk I/O Rate Share of Total VDisk Read I/O

VDisk maximum read read I/O rate is low. VDisk I/O rate share of the total VDisk read I/O rate is high as is the VDisk capacity share of total VDisk capacity.

Yes

3 VDisk Max Read Response Time, VDisk Max Read Response Time Threshold, VDisk Max Write Response Time, VDisk Max Write Response Time Threshold

Maximum read and write response times are low as is the number of hours that the maximum read and write response time thresholds are exceeded.

No

4 VDisk Max Read Cache Hits and VDisk Max Read Cache Hits Time Threshold

The maximum read cache hits is high as is the number of hours that the maximum read cache hits threshold is exceeded.

No

Final Recommendation: Migrating VDisk tpcblade4_10 will not cool off the MDisk group. Migration is not recommended.

Using storage resource groups to analyze application performanceIn IBM Tivoli Storage Productivity Center Version 4.2.2, storage resource group functionality has been extended to include reporting. In addition to grouping objects in topology view, storage resource groups can also be used to aggregate objects to provide views into performance data that transcends the boundaries that are imposed by virtualizer software.

When VDisk Workload Activity Reports is selected, the user is presented with three options. They can run a report that shows VDisks in MDisk groups, VDisks in a storage virtualizer, or VDisks in storage resource groups (see Illustration 8).


To run a storage resource group report:

1. In the VDisk Workload Activity Reports window, select Storage Resource Group – VDisk Workload Activity Report.

2. Click Next.

3. Select a storage virtualizer,

4. Enter a date range or select a date filter.

5. Click Finish.

The report compares VDisk peak utilization percentages for all of the VDisks in all of the storage resource groups in the storage virtualizer. Two charts are displayed at the top of the report which rank the most active and least active storage resource groups based on average VDisk utilization (see Illustration 9). The report can also be used to determine how well storage is performing against service level agreements. Furthermore, it is possible to view the aggregated average I/O rate or response time for all of the VDisks associated with a particular application by assigning the VDisks to a storage resource group before you run the report.


Illustration 8: Selecting a Storage Resource Group - VDisk Workload Activity Report

Illustration 9: Comparing storage resource groups in a storage virtualizer

Note: The report has been modified to present the summary lines for the two storage resource groups closer together.


Step Parameters used to determine SLA compliance

Observation Evaluation

1 VDisk Peak Utilization The SVC8vol storage resource group averaged 21.19 I/Os per second with an average of the daily maximum values coming in at 63.30 for read I/O rate.

The writes averaged 4.5 I/O per second.

This is very low utilization. Confirming with owner of the application whether this is the expected amount of I/O for the application.

2 Read and Write Response Times The SVC8vol storage resource group has an average read response time of 0.35 milliseconds per operation with a maximum of 0.45 milliseconds per operation. Write response time average and maximum write response time are 1.28 milliseconds per operation and 3.6 milliseconds per operation, respectively.

Very low response times. Storage environment is optimally configured.

Scheduling reportsYou can schedule tiering reports can to run automatically every day, every week, every month, and every year.

Note: Tiering reports use the Tivoli Storage Productivity Center's Performance Monitor to collect daily aggregated data so the data is only current as of the last day.

When you schedule reports you can set parameters to monitor specific resources to identify issues in MDisk groups, VDisks, or storage resource groups. Furthermore, you can configure reports to run interactively so that you can specify parameters, such as the name of the storage virtualizer, when you run the report.

Instead of specifying start and end dates for a report, you can use relative date ranges so that your schedule definitions remain relevant. For example, use the last 7 days as the date range instead of specifying a specific 7-day time period.

A variety of output formats are available such as:

● HTML


● PDF

● XML

● Microsoft Excel

The output of a report can be saved to the Content Store and then viewed in Tivoli Common Reporting or sent by email to specified recipients.

You can configure Tivoli Common Reporting to show the most recent report output when the report is run by default.

Sending reports by emailYou must configure email settings to work with Tivoli Common Reporting. This involves setting up the mail server to email reports.

1. On Windows OS, click Start -> All Programs -> Tivoli Common Reporting 2.1.1 -> IBM Cognos Configuration.)

2. In the Explorer panel, expand Data Access and click Notification.

In the Notification - Component Properties panel, make the following changes:

i. Set the value for SMTP mail server.ii. Edit the account and password information.iii. Save your changes.

3. Click the Restart button to restart IBM Cognos®.

Creating a report viewYou can create a report view, which uses the same report specification as the source report, but has different properties such as prompt values , schedules, run options, languages , and output formats.

Let's create a report view with the following settings:

● The report runs every week

● The report provides output for the last 7 days

● The report generates a PDF file in landscape format

● The report output language is French

1. To create the report view, click the Report View icon.

2. (Optional) Rename report view.

3. (Optional) Choose a folder to store the report.

4. Click Finish.

5. Click the icon to open the Report View schedule.


6. Set the properties for the report.

i. Select French as the language for the report.

7. Open the Report View tabbed page.

i. Default Action: Run the Report

ii. Override the default values.

iii. Configure the PDF settings.

iv. Set the orientation of the PDF file output to Landscape.

v. Configure the prompt values.

i. Select Storage Virtualizer.

ii. Choose Last 7 days as the date range.

8. Click OK.

1. Open the report view schedule again.

i. Select Monday.


ii. Click OK.

Locating related documentationTo learn more about storage tier reports:

1. Click this link: Tivoli Storage Productivity Center Information Center.

2. Click IBM Tivoli Storage Productivity Center Version 4.2.2.

3. Expand the Reporting node.

4. Expand Storage tier reports.

5. Expand Using Tivoli Common Reporting to run storage tier reports.

6. See the topics bout the reports, and the topic about the read I/O capability formula.

To learn more about setting MDisk group back-end pool characteristics using the CLI:

1. Click this link: Tivoli Storage Productivity Center Information Center.

2. Click IBM Tivoli Storage Productivity Center Version 4.2.2.

3. Expand the Reference node.

4. Expand the Commands node.

5. Expand the tpctool command node.

6. See the following topics:

Topic Short description

setarray The setarray command is used to set the type of back-end storage system, type of Redundant Array of Independent Disks (RAID), type of disk, and number of disks for an array.

autosetarray The autosetarray command is used to extract and save information about storage pools. You can save information about a storage pool such as the type of back-end storage system, type of RAID, and type of disk. To do this you use a default pattern or create a pattern that matches the names of pools in a subsystem. If the match is successful, the information about the pool is extracted and saved.

setbackendtype The setbackendtype command is used to set or update the type of back-end storage system.


http://publib.boulder.ibm.com/infocenter/tivihelp/v4r1/index.jsp

http://publib.boulder.ibm.com/infocenter/tivihelp/v4r1/index.jsp

Topic Short description

setbackenddisktype The setbackenddisktype command is used to set or update the type of back-end disk.

setbackendraidtype The setbackendraidtype command is used to set the type of back-end RAID arrays.


Appendix 1: SQL query for retrieving back-end dataselect distinct virtualizer.display_name as virtualizer, mdisk_group.display_name as mdisk_group, ss.type as backend_ss, ss_pool.display_name as backend_pool, ss_pool.raid_level as pool_raid_level,(select count(*) from tpcreport.storageextent se, tpcreport.diskdrive2storageextent dd2se where se.storage_extent_id = dd2se.storage_extent_id and se.pool_id = ss_pool.pool_id ) as pool_num_disks ,(select count(*)from tpcreport.storagesubsystem_rank r, tpcreport.storagesubsystem_arraysite arr, tpcreport.diskdrive ddwhere r.pool_id = ss_pool.pool_idand r.storage_extent_id = arr.storage_extent_idand arr.disk_group_id = dd.disk_group_idand dd.flags != 'SPARE_DEVICE') as ds6k_8k_pool_num_disksfrom tpcreport.storagesubsystem virtualizer, tpcreport.storagepool mdisk_group, tpcreport.backenddisk mdisk, tpcreport.storagevolume sv, tpcreport.storagepool ss_pool, tpcreport.storagesubsystem sswhere mdisk_group.primordial = 'False' and mdisk_group.subsystem_id = virtualizer.subsystem_id and virtualizer.type in ('SVC','Storwize V7000')and mdisk_group.pool_id = mdisk.pool_idand mdisk.storage_extent_id = sv.backend_disk_idand sv.pool_id = ss_pool.pool_idand ss_pool.subsystem_id = ss.subsystem_idorder by virtualizer;


© Copyright IBM Corporation 2011

All Rights Reserved.

IBM Systems and Technology Group

Route 100

Somers, New York 10589

Printed in United States of America

10-11

Neither this documentation nor any part of it may be copied or

reproduced in any form or by any means or translated into another

language, without the prior consent of all of the above mentioned

copyright owners.

IBM makes no warranties or representations with respect to the

content hereof and specifically disclaims any implied warranties of

merchantability or fitness for any particular purpose. IBM assumes no

responsibility for any errors that may appear in this document. The

information contained in this document is subject to change without

any notice. IBM reserves the right to make any such changes without

obligation to notify any person of such revision or changes. IBM

makes no commitment to keep the information contained herein up to

date.


The information in this document concerning non-IBM products was

obtained from the supplier(s) of those products. IBM has not tested

such products and cannot confirm the accuracy of the performance,

compatibility or any other claims related to non-IBM products.

Questions about the capabilities of non-IBM products should be

addressed to the supplier(s) of those products.

IBM, the IBM logo, DB2, DB2 Universal Database, and Tivoli are

trademarks or registered trademarks of International Business

Machines Corporation in the United States, other countries, or both.

Microsoft is a trademark of Microsoft Corporation in the United States, other countries, or both.

Other company, product, or service names may be trademarks or

service marks of others.

References in this publication to IBM products or services do not

imply that IBM intends to make them available in all countries in

which IBM operates.


Storage Tier Reports - · PDF fileStorage tier reports help users to engage in capability...

Documents

Transcript of Storage Tier Reports - · PDF fileStorage tier reports help users to engage in capability...