IBM Tivoli Storage Productivity Center Version Storage Tier Reports. Authors: Mike Lamb Patrick Leahy Balwant Rai Jackson Shea

Transcription

1 IBM Tivoli Storage Productivity Center Version Authors: Mike Lamb Patrick Leahy Balwant Rai Jackson Shea

2 Contents Introduction...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 Creating a report view...27 Locating related documentation...29 Appendix 1: SQL query for retrieving back-end data...31 page 2 of 33

3 Introduction The inclusion of storage tier reports in IBM Tivoli Storage Productivity Center Version 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 prerequisites It 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 concepts Storage virtualizers In this white paper, the term storage virtualizer is used to refer to SAN Volume Controller and Storwize V7000 storage systems. Capacity versus capability Capability 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. page 3 of 33

4 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-tiering Up-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 characteristics General 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.) page 4 of 33

5 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). page 5 of 33

6 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 data The 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 MDisks In 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 nonds6k or DS8K disk totals in a separate column. page 6 of 33

7 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) Parity + Spare versus 7 + Parity are RAID descriptions of how 8-disk RAID sets are designated. page 7 of 33

8 In this scenario, GB volumes and GB volumes are created. On storage virtualizers, it is best practice to group the 1844 GB into one or more MDisk groups and the 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 workloads As 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. page 8 of 33

9 MDISK GROUP: XIV1_0 MDISK:XIV1_LV35... SVC MDISK:XIV1_LV02 MDISK:XIV1_LV01 MDISK:XIV1_LV00 LV GB... LV GB XIV1 1TB 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 page 9 of 33

10 Easy Tier, Storage Optimizer, and storage tier reports IBM 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 uptiering or down-tiering Description The 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 page 10 of 33

11 Analyzing storage tier reports Illustration 7: Use case workflow 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). page 11 of 33

12 Steps for analyzing MDisk groups 1. 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 Step 1 Step 2 Column Name Description Comment 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 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. MDisk group workload is considered to be least active when consumed capacity is high and capability is under utilized. 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 workload is considered to be most active when capacity is highly available and capability is highly utilized. 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 when the rate of consumed capacity is high and capability is under utilized. MDisk Group Real Capacity (GB) MDisk Group Capacity 100) 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 page 12 of 33

13 Step Step 3 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. 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 Max8 Read The number of hours and Response Time minutes that the maximum Threshold read response time threshold is exceeded over a 24 hour period. MDisk group workload is considered to be most active when the number of hours and minutes that exceed the threshold is high. MDisk Group9 Average Read Response Time The average read response time in milliseconds per operation. MDisk group workload is considered to be most active when the average read response time is high. MDisk Group Max Write Response Time The maximum write response time in milliseconds per operation. MDisk group workload is considered to be most active when the maximum response time is high. 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. MDisk group workload is considered to be most active when the number of hours and minutes that exceed the threshold is high. Steps for analyzing VDisks The 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%. page 13 of 33

14 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 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 VDisk workload is considered to be most active when the maximum read I/O rate is high. VDisk Max Read Response Time The maximum read response time in milliseconds per operation. Step 3 VDisk Max Read Response Time Threshold VDisk Max Write Response Time VDisk Max Write Response Time Threshold VDisk workload is considered to be most active when the rate of maximum read I/O rate of I/O share of total VDisk all the VDisks in the read I/O is high and the MDisk group. capacity share of total VDisk capacity is low. VDisk workload is considered to be most active when the maximum read response time and the number of hours and The number of hours and minutes that the minutes that the maximum read maximum read response response time threshold time threshold for the is exceeded are high. VDisk is exceeded over a 24 hour period. VDisk workload is considered to be most active when the The maximum write maximum write response time in response time and the milliseconds per number of hours and operation. minutes that the maximum write The number of hours and response time threshold is exceeded are high. minutes that the maximum write response page 14 of 33

15 Steps Column Name Description Comment time threshold for the VDisk is exceeded over a 24 hour period. Step 4 VDisk Max Read Cache Hits VDisk Max Read Cache Hits Time Threshold The maximum read cache hits in percent. VDisk workload is considered to be most active when the maximum read cache The number of hours and hits and the number of minutes that the hours and minutes that maximum read cache hits the maximum read time threshold is cache hits time exceeded over a 24 hour threshold is exceeded period. are high. page 15 of 33

16 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. page 16 of 33

17 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 overutilized (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. Yes Final recommendation Maximum and average write response times are high. The number of hours that the write response time exceeds the threshold is too high. 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 page 17 of 33

18 Step Parameters used to determine tiering Observation 1 MDisk Group Read I/O Rate Capability, MDisk Group Max Read I/O Rate, MDisk Group Read I/O Rate Availability 2 MDisk Group Capacity Status, MDisk The capacity status is set to No Group Capacity, MDisk Group Real Warning. Capacity, MDisk Group Free Space Consumed capacity is high (79.90 GB), and capability utilization is low fluctuating between 10% and 20%. 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 Final Recommendation: 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%. Up-tiering recommended Maximum and average read response times are high. No No Maximum and average write response times are high, and the number of hours that the write response exceeds the threshold is too high. MDisk Group cognos is not over-utilized and its workloads are not recommended for up-tiering. page 18 of 33

19 Analyzing the mdiskgrp1 MDisk group for down-tiering Step Parameters used to determine tiering Observation 1 MDisk Group Read I/O Rate Capability, MDisk Group Max Read I/O Rate, MDisk Group Read I/O Rate Availability 2 MDisk Group Capacity Status, MDisk The capacity status is set to Group Capacity, MDisk Group Real Warning. Capacity utilization is Capacity, MDisk Group Free Space 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 Yes Final Recommendation: The availability rate is very high. Down-tiering recommended Maximum and average read response times are very low. Yes Maximum and average write response times are OK and the number of hours that the write response exceeds the threshold is too high. MDisk Group mdiskgrp1 is under-utilized and its workloads are strongly recommended for downtiering. page 19 of 33

20 Analyzing the deletemdiskgrp3 MDisk group for down-tiering Step Parameters used to determine tiering Observation 1 MDisk Group Read I/O Rate Capability, MDisk Group Max Read I/O Rate, MDisk Group Read I/O Rate Availability 2 MDisk Group Capacity Status, MDisk The capacity status is set to OK, Group Capacity, MDisk Group Real but there is little free space. Capacity, MDisk Group 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 Yes Final Recommendation: Availability is high. Down-tiering recommended Response times are reasonable. Yes MDisk Group deletemdiskgrp3 is under utilized and its workloads are recommended for down-tiering. page 20 of 33

21 Identifying most active VDisks to reduce MDisk group workload Analyzing the tvt VDisk The 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. Step Parameters used to determine tiering Observation Up-tiering recommended 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 page 21 of 33

22 Step Parameters used to determine tiering Observation Up-tiering recommended 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 Yes times are high and the number of hours that the read and write response time thresholds are exceeded are high. 4 VDisk Max Read Cache Hits and The maximum read cache Yes VDisk Max Read Cache Hits hits and the number of hours Time Threshold that the maximum read cache hit threshold is exceeded is high. 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 VDisk The 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. page 22 of 33

23 Step 1 2 Parameters used to determine tiering VDisk Peak Utilization Observation VDisk peak utilization is low. Up-tiering recommended Yes VDisk maximum read read VDisk Max Read I/O Rate, VDisk I/O Yes I/O rate is low. VDisk I/O Rate Share of Total VDisk Read I/O rate share of the total VDisk read I/O rate is high as is the VDisk capacity share of total VDisk capacity. 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 No response times are low as is the number of hours that the maximum read and write response time thresholds are exceeded. 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. Final Recommendation: No Migrating VDisk tpcblade4_10 will not cool off the MDisk group. Migration is not recommended. Using storage resource groups to analyze application performance In 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). page 23 of 33

24 Illustration 8: Selecting a Storage Resource Group - VDisk Workload Activity Report 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. page 24 of 33

25 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. page 25 of 33

26 Step Parameters used to determine SLA compliance 1 VDisk Peak Utilization Observation The SVC8vol storage resource group averaged I/Os per second with an average of the daily maximum values coming in at for read I/O rate. The writes averaged 4.5 I/O per second. 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. Evaluation This is very low utilization. Confirming with owner of the application whether this is the expected amount of I/O for the application. Very low response times. Storage environment is optimally configured. Scheduling reports You 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 page 26 of 33

27 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 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 You must configure settings to work with Tivoli Common Reporting. This involves setting up the mail server to reports. 1. On Windows OS, click Start -> All Programs -> Tivoli Common Reporting > 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 view You 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. page 27 of 33

28 6. Set the properties for the report. i Select French as the language for the report. 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. Click OK. Open the report view schedule again. i. Select Monday. page 28 of 33

29 ii. Click OK. Locating related documentation To learn more about storage tier reports: 1. Click this link: Tivoli Storage Productivity Center Information Center. 2. Click IBM Tivoli Storage Productivity Center Version 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 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. page 29 of 33

30 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. page 30 of 33

31 Appendix 1: SQL query for retrieving back-end data select 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 dd where r.pool_id = ss_pool.pool_id and r.storage_extent_id = arr.storage_extent_id and arr.disk_group_id = dd.disk_group_id and dd.flags!= 'SPARE_DEVICE') as ds6k_8k_pool_num_disks from tpcreport.storagesubsystem virtualizer, tpcreport.storagepool mdisk_group, tpcreport.backenddisk mdisk, tpcreport.storagevolume sv, tpcreport.storagepool ss_pool, tpcreport.storagesubsystem ss where 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_id and mdisk.storage_extent_id = sv.backend_disk_id and sv.pool_id = ss_pool.pool_id and ss_pool.subsystem_id = ss.subsystem_id order by virtualizer ; page 31 of 33

32 Copyright IBM Corporation 2011 All Rights Reserved. IBM Systems and Technology Group Route 100 Somers, New York Printed in United States of America 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. page 32 of 33

33 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. page 33 of 33