performance benefits of ibm storwize v7000 with easy · pdf fileperformance benefits of ibm...

© Copyright IBM Corporation, 2011.

Performance benefits of IBM Storwize V7000 with Easy Tier for

Oracle 11g workload

Configurations and performance benefits

Mayur Shetty

IBM Systems and Technology Group ISV Enablement

January 2011

Performance benefits of IBM Storwize V7000 with IBM Easy Tier for Oracle 11g workload

Table of contents

1 Abstract.................................................................................................................................. 1

2 Introduction ........................................................................................................................... 1 2.1 Overview ........................................................................................................................................... 1 2.2 Assumptions .................................................................................................................................... 1 2.3 Intended audience ........................................................................................................................... 2

3 IBM Storwize V7000 technology stack ................................................................................. 2 3.1 IBM Storwize V7000 overview......................................................................................................... 2 3.1.1 IBM Storwize V7000 functionalities............................................................................................. 2 3.1.2 IBM Storwize V7000 terminology ................................................................................................ 4

4 IBM Storwize V7000 and Easy Tier ....................................................................................... 5 4.1 Easy Tier Overview.......................................................................................................................... 5 4.2 Easy Tier functionality .................................................................................................................... 5 4.3 Easy Tier mechanism to move data............................................................................................... 6

4.3.1 Automatic mode .................................................................................................... 6 4.3.2 Manual mode.......................................................................................................... 6

4.4 Data relocation options with Easy Tier ......................................................................................... 6

5 Oracle random I/O workload tested...................................................................................... 7

6 IBM Storwize V7000 with Easy Tier configuration............................................................... 7 6.1 SAN configuration planning ........................................................................................................... 7 6.2 MDisk configuration ........................................................................................................................ 7 6.3 Adding solid-state drives to the storage pool configuration .................................................... 12 6.4 Volume configuration.................................................................................................................... 16 6.5 Mapping volumes to the host:...................................................................................................... 18

7 Monitoring and modeling tools .......................................................................................... 21 7.1 IBM Tivoli Storage Productivity Center(TPC) ............................................................................. 21 7.2 IBM Storage Tier Advisor Tool ..................................................................................................... 22

8 I/O workload calibration tools............................................................................................. 22 8.1 Vdbench overview ......................................................................................................................... 22 8.2 ORION overview............................................................................................................................. 23

9 Lab setup ............................................................................................................................. 23

10 Testing methodology ........................................................................................................ 24 10.1 IBM Storwize V7000 Storage configuration used for the test runs ........................................ 24

10.1.1 Easy Tier configuration ..................................................................................... 25 10.2 Linux host configuration used for the test runs....................................................................... 30 10.3 Vdbench test run description ..................................................................................................... 30

10.3.1 OLTP only............................................................................................................ 30 10.4 ORION test run description ........................................................................................................ 32

10.4.1 OLTP only............................................................................................................ 32

11 Easy Tier test results......................................................................................................... 32 11.1 Oracle OLTP workload using Vdbench ..................................................................................... 32

Performance benefits of IBM Storwize V7000 with IBM Easy Tier for Oracle 11g workload

11.1.1 OLTP workload without Easy Tier configured ................................................ 32 11.1.2 OLTP workload of 100 percent random reads with Easy Tier configured ... 33 11.1.3 OLTP workload of 70 percent random reads and 30 percent random writes with Easy Tier configured............................................................................................. 34 11.1.4 OLTP workload of 50 percent random reads and 50 percent random writes with Easy Tier configured............................................................................................. 35

11.2 Oracle OLTP workload using ORION......................................................................................... 36 11.2.1 OLTP workload without Easy Tier configured ................................................ 36 11.2.2 OLTP workload with Easy Tier configured ...................................................... 38

12 Summary............................................................................................................................ 40

Resources............................................................................................................................... 41

Trademarks and special notices ........................................................................................... 42

Performance benefits of IBM Storwize V7000 with IBM Easy Tier for Oracle 11g workload 1

1 Abstract

This paper demonstrates the performance benefits of running an Oracle 11g database on IBM Storwize V7000 with IBM Easy Tier enabled. The paper also explains online transaction processing (OLTP) workload and I/O workload that is generated using Oracle ORION and Vdbench load generator tools.

2 Introduction This section provides an overview on the various topics explained in this paper, the assumptions made, and the intended audience that are likely to benefit from this paper.

2.1 Overview

This paper demonstrates the performance benefits that IBM® Easy Tier™ provides by seamlessly migrating hot extents from hard disk drives (HDDs) to a higher performing solid-state drives within the IBM Storwize V7000 solution. This might be either to internal solid-state drives in the IBM Storwize V7000 or to external storage systems that are virtualized by IBM Storwize V7000.

The other load generator tool that has been used here is Oracle Vdbench. The objective of Vdbench is to generate a wide variety of controlled storage I/O workloads, allowing control over workload parameters such as I/O rate, logical unit number (LUN) or file sizes, transfer sizes, thread count, volume count, volume skew, read/write ratios, read and write cache hit percentages, and random or sequential workloads.

The other load generator used to arrive at the configuration guidelines is the Oracle I/O Calibration Tool ORION) calibration tool. This tool generates I/O using the same I/O software stack used by the Oracle server software without having to install the server software and create a database. It can simulate various workload types at different load levels to arrive at performance metrics for input/output operations per second (IOPS), and latency (response time). It can also simulate the effect of striping performed by Automatic Storage management (ASM).

The intention of this paper is not to demonstrate the maximum possible I/O benchmark or performance number for the IBM Storwize V7000. Those benchmark and performance numbers are likely to be shown in the Storage Performance Council SPC-1 and SPC-2 results posted by IBM on the SPC website. This paper demonstrates how to configure Easy Tier, and explains how Easy Tier might benefit the performance for an Oracle database workload by optimizing the utilization of solid-state drives.

2.2 Assumptions

The team assumes that the best practices that are documented in the IBM Storwize V7000 Introduction and Implementation Guide from IBM Redbook® holds good for Oracle databases too.

Another assumption is that the load generation tools, Oracles Vdbench and ORION, are appropriate for determining storage performance for Oracle I/O workloads. A detailed description of both the tools is provided in a later section. But briefly, ORION generates I/O using the same I/O software stack used by the Oracle server software without having to install the server software. By using ORION, it is possible to avoid addressing the subject of Oracle database server tuning, which is beyond the scope of this paper.

Also, Vdbench generates a wide variety of controlled storage I/O workloads, allowing control over workload parameters such as I/O rate, LUN or file sizes, transfer sizes, thread count, volume count,


volume skew, read/write ratios, read and write cache hit percentages, and random or sequential workloads.

2.3 Intended audience

The intended audience of this paper is any technical lead, system administrator, storage administrator, or an Oracle database administrator (DBA) who is planning on deploying the IBM Storwize V7000 for running Oracle database. This paper provides a starting point for Easy Tier configuration, as well as provides an idea on how Easy Tier optimally utilizes solid-state drives, and provides the performance benefit for an Oracle database workload.

3 IBM Storwize V7000 technology stack This section includes concepts related to the IBM Storwize V7000.

3.1 IBM Storwize V7000 overview

The IBM Storwize V7000 solution provides a modular storage system that includes the capability to virtualize external storage area network (SAN) attached storage as well as its own internal storage. IBM Storwize V7000 provides a number of preset configuration options which are aimed at simplifying the implementation process. It also provides an active-active solution, and is a clustered, scalable, midrange storage, as well as an external virtualization device.

Included with IBM Storwize V7000 is a simple and easy to use graphical user interface (GUI) that allows storage to be deployed quickly and efficiently. The GUI runs on the IBM Storwize V7000 system so there is no need for a separate console. The IBM Storwize V7000 solution consists of a control enclosure which is a hardware unit that includes the chassis, node canisters, drives, and energy sources that include batteries, and expansion enclosures which is a hardware unit that includes expansion canisters, drives, and energy sources that do not include batteries. Within each enclosure are two canisters which are hardware units that includes the node hardware, fabric and service interfaces, and serial-attached SCSI (SAS) expansion ports, which determine the role of the enclosure

3.1.1 IBM Storwize V7000 functionalities

The following functionalities are available with the IBM Storwize V7000:

• Thin provisioning: With thin provisioning, applications can grow dynamically, but consume only the space that they are actually using. Without thin provisioning, preallocated space is reserved irrespective of whether the application uses it or not.

• Volume Mirroring: Volume Mirroring provides a single volume image to the attached host systems while maintaining pointers to two copies of data in separate storage pools. Copies can be on completely separate disk storage systems that are being virtualized.

• IBM FlashCopy®: FlashCopy creates instant application copies that can be used for backup or application testing. FlashCopy makes better use of space with incremental copy where only changed blocks are copied.


• Metro Mirror: Metro Mirror provides synchronous remote mirroring function up to approximately

300 km between sites. As the host I/O completes only after the data is cached at both locations, performance requirements may limit the practical distance. Metro Mirror is designed to provide fully-synchronized copies at both sites with zero data loss after the initial copy is completed.

• Global Mirror: Global Mirror provides long distance asynchronous remote mirroring function up to approximately 8,000 km between sites. With Global Mirror, the host I/O completes locally, and the changed data is sent to the remote site later. This is designed to maintain a consistent, recoverable copy of data at the remote site which lags behind the local site.

• Data migration: A data migration wizard can be used to import external storage system into the IBM Storwize V7000.

• Easy Tier: Provides a mechanism to seamlessly migrate hot spots to a higher performing storage pool within the IBM Storwize V7000 solution. This can be to internal drives within IBM Storwize V7000 or to external storage systems that are virtualized by IBM Storwize V7000.

Figure 1: IBM Storwize V7000 virtualizing external and internal storage


3.1.2 IBM Storwize V7000 terminology

Table 1 lists the Storwize V7000 terminology used in the paper. For an entire list of the Storwize V7000 terminology, refer to the IBM Storwize V7000 Introduction and Implementation Guide.

IBM Storwize V7000 term Definition

Control enclosure A hardware unit that includes the chassis, node canisters, drives, and energy sources that include batteries.

Expansion enclosure A hardware unit that includes expansion canisters, drives, and energy sources that do not include batteries.

Node canister A hardware unit that includes the node hardware, fabric and service interfaces, and serial-attached SCSI (SAS) expansion ports.

Host mapping The process of controlling in which hosts have access to specific volumes within a cluster.

Internal storage Array managed disks and drives that are held in enclosures and nodes that are part of the cluster.

Managed disk (MDisk) A component of a storage pool that is managed by a cluster. An MDisk is either part of a RAID array of internal storage or a Small Computer System Interface (SCSI) logical unit (LU) for external storage. An MDisk is not visible to a host system on the SAN.

Storage pool A collection of storage capacity that provides the capacity requirements for a volume.

Thin provisioning or thin provisioned

The ability to define a storage unit (full system, storage pool, or volume) with a logical capacity size that is larger than the physical capacity assigned to that storage unit.

Volume

A discrete unit of storage on disk, tape, or other data recording medium that supports some form of identifier and parameter list, such as a volume label or input/output control

Extent

Each MDisk is divided into segments of equal size called extents. When a volume is created from a storage pool, the volume is allocated based on the number of extents required to satisfy the capacity requirements for the volume.

Table 1: IBM Storwize V7000 terminology


4 IBM Storwize V7000 and Easy Tier This section gives an overview of the Easy Tier feature in the Storwize V7000 and mechanism in which Easy Tier moves the data between the tiers in the storage pool.

4.1 Easy Tier Overview

Easy Tier is designed to determine the appropriate tier of storage based on data access requirements, and then automatically and non-disruptively move data, at the sub-volume or sub-LUN level, to the appropriate tier. This feature is designed to reduce, if not eliminate, the amount of manual effort involved. In this new dynamic environment, data movement is seamless to the host application regardless of the storage tier in which the data resides.

4.2 Easy Tier functionality

Easy Tier performs the following three functions:

• Workload monitoring: During the workload monitoring stage, Easy Tier determines if the data on the HDD tier needs to be promoted to the solid-state drive tier, or whether the data on the solid-state drive tier needs to be demoted to the HDD tier.

• Workload analysis: Easy Tier can provide information on data access patterns that can be used for solid-state drive capacity planning.

• Smart data migration: Easy Tier seamlessly relocates data to the appropriate tier. The data movement is seamless to the host application regardless of the storage tier in which the data resides.

Figure 2: Easy Tier overview


4.3 Easy Tier mechanism to move data

There are two different mechanisms based on which data can be moved between tiers in Easy Tier. They are:

• Automatic mode

• Manual mode

4.3.1 Automatic mode

In this mode, Easy Tier monitors the access to extents on a logical volume and, based on storage usage, automatically and nondisruptively relocates the hottest data (in the form of extents) to an appropriate storage device in a managed extent pool.

A storage pool that is managed by Easy Tier requires at least one solid-state drive MDisk and one non-solid-state drive MDisk. You can also create a mixed extent pool that is managed by Easy Tier by:

• Creating a storage pool with solid-state drive and HDD MDisks. • Adding solid-state drive MDisk to an existing HDD storage pool • Adding HDD MDisk to an existing solid-state drive storage pool • Merging an existing solid-state drive and an existing HDD storage pool

After a storage pool is formed, you can add additional MDisks to the managed storage pool or additional storage pools can be merged with this storage pool. Volumes that are created in managed storage pools are allocated on HDD extents based on the monitoring process and algorithms used by Easy Tier, which might later be migrated to solid-state drives.

4.3.2 Manual mode

In this mode, you can dynamically relocate a logical volume between extent pools or within an extent pool to change the extent allocation method of the volume or to redistribute the volume across new MDisks that have been added. This capability is referred to as dynamic volume relocation.

4.4 Data relocation options with Easy Tier

Initial implementation will have the following two tiers:

• Generic solid-state drive which is tier 0

• Generic HDD which is tier 1

Internal drives have tiers chosen by IBM Storwize V7000, while external (SAN) MDisks have a tier assigned by the user. Easy Tier between solid-state drive and SAS or Fibre Channel (FC) drives have been tested, but nothing in the product disallows other combinations. For example, SAS to Near Line SAS is allowed but will not be tested. Using Easy Tier with other disk configurations can lead to unpredictable performance and need to be tested before production implementation. Easy Tier is


designed to work with IBM Storwize V7000 internal solid-state drives or SAN based external solid-state drives.

Easy Tier is supported in both mirrored volumes and thin-provisioned volumes. In the case of mirrored volumes, both copies are independently managed by Easy Tier, while in thin-provisioned volumes only the real storage is subject to Easy Tier management.

In the case of sequential volumes, where the extents are allocated one after another in one MDisk, they can be measured but not managed by Easy Tier. Also, in image mode volumes, which are special volumes that have direct relationship with one MDisk and which are used to migrate existing data in and out of the V7000 cluster, the volumes can be measured but not managed by Easy Tier.

Easy Tier is also supported for FlashCopy source and target volumes. Metro Mirror and Global Mirror primary and secondary volumes are also supported with Easy Tier, but the Metro Mirror and Global Mirror volumes do not inherit characteristics of the primary as part of the disaster recovery activity.

5 Oracle random I/O workload tested The Oracle I/O workload tested here is small-block (8KB), random I/Os.

Online transaction processing (OLTP) applications usually generate small random I/O workload, where the response time of the I/O request is very important. OLTP workloads are transaction based, where the performance is measured by IOPS and the response time. OLTP database block size usually ranges from 2 KB to 32 KB, with 8 KB being the average

6 IBM Storwize V7000 with Easy Tier configuration This section talks about the configuration of various components that were involved in testing. It includes: SAN configuration, MDisks configuration, storage pools, volumes, and hosts.

6.1 SAN configuration planning

For the best practices on SAN configuration planning, refer to the IBM Storwize V7000 Introduction and Implementation Guide from IBM Redbooks.

6.2 MDisk configuration

In Storwize V7000, the internal drives cannot be directly added to storage pools. They need to be included in a Redundant Array of Independent Disks (RAID) to provide protection against the failure of individual drives. A RAID array is created as a MDisk, and during the array creation, wizards and presets are available to suggest configurations to users based on the hardware attached to the system. The recommendation is to use these presets for easy configuration and best performance.

The following content shows how to create arrays on the system using the GUI. The Storwize V7000 command line interface (CLI) might not be needed though it is flexible in most cases.

When you first setup the Storwize V7000, the initial setup wizard prompts the user to use the fully-automated RAID setup. Now, start from the Getting Started screen on the GUI, as shown in Figure 3.


Figure 3: Getting started with the storage configuration

Figure 4 shows the internal solid-state drives with an Online status before the MDisk configuration.

Figure 4: Internal solid-state drive storage

You can choose to use the recommended (fully-automatic) configuration or a different configuration for customization. (Refer to Figure 5). In this example, a different configuration has been used. In this


step, first select the drive class. The GUI then provides a preset list based on the drive class. You can decide whether to configure spares automatically, and optimize the array for performance or capacity. You can also indicate the number of drives to be provisioned. The configuration summary seen at the bottom of Figure 5 displays information on what the system will attempt to do, or indicate it cannot meet the RAID creation requirement.

The team configured the internal SAS drives, and chose the preset of Basic RAID-10. In this example, the team used 32 drives, optimized for performance.

Figure 5: HDD MDisk creation

With the Optimize for Performance option, all arrays in a pool will have the same performance characteristics, and potentially leave unused drives in the system. The Optimize for Capacity option uses all drives in the system, which means that some of the arrays may not meet the array width goals. It will do this by reducing the number of drives in one or more arrays to be created by an equal amount, and you will get an optimal performance layout (all arrays have the same width, or the width with one drive more or one drive less, but the width will not be the same as the width goal).

Note: If the perfect number of drives exists, the Optimize for Capacity option creates the same layout as the Optimize for Performance option. Both the algorithms are explained in the Implementing IBM Storwize V7000 Redbook.


Next, you need to decide whether to expand an exiting pool or create one or more new pools with the arrays. In this example, a new pool dedicated for internal storage (as shown in Figure 6) has been created.

Figure 6: Creating a new storage pool

Now, you will see the new storage pool creation progress and the command line result, if the Details option is turned on (as shown in Figure 7).


Figure 7: Details of the RAID arrays creation

When you navigate to the Pools page, you can notice that a new test_easytier pool has been created, and it has four members mdisk0, mdisk1, mdisk2 and mdisk3, all having an Online status (as shown in Figure 8).


Figure 8: Storage pools and arrays status

You have now completed managing the internal HDDs. Next, you will see how to manage the internal solid-state drives.

6.3 Adding solid-state drives to the storage pool configuration

Storage pool is a collection of MDisks providing real capacity for the creation of volumes. You can add solid-state drive MDisks to the storage pool at any time to increase the capacity of the storage pool, and to activate Easy Tier. All the MDisks in a storage pool are split into segments of equal size called extents.

You can choose to use the recommended (fully-automatic) configuration or a different configuration for customization (refer to Figure 5). In this example, a different configuration has been used. In this step, the team first selected the preset SSD Easy Tier option. In this example, the team used six drives optimized for performance, and created three solid-state drive Easy Tier MDisks.


Figure 9: Solid-state drive MDisk creation – step 1


Figure 10: Solid-state drive MDisk creation – step 2

Figure 11: Adding the solid-state drive MDisks to an existing storage pool


Figure 12: Details of adding the solid-state drive MDisks to an existing storage pool

Figure 13: Solid-state drive MDisks


Figure 14: Easy Tier active with HDD and solid-state drive MDisks

6.4 Volume configuration

A volume is a logical disk that is presented to a host system by the IBM Storwize V7000. The IBM Storwize V7000 storage translates this volume into a number of extents which are allocated across MDisks present in the storage pool.


Click Volumes by Pool from the pop-up menu on the side bar of the screen to open the Volumes by Pool panel. Click New Volume to launch the New Volume wizard. Then select the storage pool from which you want to create volumes. Enter the volume name and the size of the volume that you would like to create. Click on the + sign to create additional volumes, as shown in Figure 15.

Figure 15: New Volume wizard

Figure 16 shows detailed messages that are displayed when you click Create and Map to Host in the new volume creation wizard.


Figure 16: Volumes by pool panel

6.5 Mapping volumes to the host:

A host system is connected to the Storwize V7000 through either a Fibre Channel connection or an iSCSI connection. For this paper, the team used Fiber Channel to connect host to the IBM Storwize V7000. Hosts are defined to IBM Storwize V7000 by identifying their worldwide port names (WWPNs) for Fibre Channel hosts.

After viewing the details, when you click Continue, (as shown in Figure 16) the Modify Mappings dialog box (as shown in Figure 17) is displayed. In this example, the volumes are mapped to host isvx7, which is selected from the drop down list.


Figure 17: Mapping volumes to host isvx7

Clicking Next takes you to the Modify Mappings screen, as shown in Figure 18.

Figure 18: Mapped volumes

On clicking OK, you can see that the volumes are mapped to the host, as shown in Figure 19.


Figure 19: Host mappings

Move the mouse pointer over a volume name, in this case, vol01. Then right-click and click Properties. This shows the details on the volume, in the three tabs: Overview, Host Maps, and Member MDisks.

Under the Member MDisk tab, in the # of Extents column, for vol01, it shows 500 for mdisk0, 500 for mdisk1, 500 for mdisk2, and 500 for mdisk3. The reason for this is that the size of volume vol01 is 500 GB, and the extent size of the test_easytier storage pool is 256 MB. Therefore, 256x500 = 128 MB, which is the size of the vol01 on mdisk0. There are four HDD MDisks in the storage pool, and therefore 128x4 = 512 GB, which is roughly the size of the volume vol01 that the team had created.

You will see later that as the test progresses Easy Tier analyzes the I/O pattern and develops a migration plan for the hot extents in each of the HDD Mdisks. During the extent migration phase, you will see three more solid-state drive mdisks in the member MDisk screen. The number under the # of Extents column starts reducing as the hot extents migrate from the HDD MDisks to the solid-state drive MDisks, until all the solid-state drive extents have been used.


Figure 20: Number of extents in a volume

7 Monitoring and modeling tools In this section we talk about two tools that can be used with IBM Storwize V7000 to give an insight into the performance of the storage, and to predict whether the addition of Solid State Drive (SSD) capacity in conjunction with the Easy Tier function could benefit system performance.

7.1 IBM Tivoli Storage Productivity Center (TPC)

IBM Tivoli® Storage Productivity Center for Disk is an essential tool in an IBM SAN environment to help ensure good data center reliability. Tivoli Storage Productivity Center for Disk offers the following features:

• A graphical overview of the entire data center topology, from hosts to Fibre Channel switches to storage.

• The ability to drill down into each object in the topology. For example, you can select a given storage controller and expand it to view all the layers of the virtualization hierarchy.

• Collection of very detailed performance data on LUNs, RAID arrays, switches, and so on.

For example, for a given LUN over a specified time period, you can see the IOPS, the response time, the throughput, and the read or write cache hit ratio.

A wide range of reports can be produced and used to analyze SAN-wide performance data.


Tivoli Storage Productivity Center for Disk allows you to monitor and report on all the layers of the technology stack in an IBM SAN environment, and is an important component in the setup of a data center.

For more information about IBM Tivoli Storage Productivity Center, visit

ibm.com/systems/storage/software/center/

7.2 IBM Storage Tier Advisor Tool

The IBM Storage Tier Advisor Tool is a Microsoft® Windows® console application that analyzes heat data files produced by Easy Tier and produces a graphical display of the amount of hot data per volume and predictions of how additional solid-state drive capacity might benefit performance for the system and by storage pool. This version of the Storage Tier Advisor Tool supports heat data files produced by Easy Tier on SAN Volume Controller 6.1, Storwize V7000, and IBM System Storage® DS8000® 5.1, and DS8000 5.1.5.

Heat data files are produced approximately one time a day when Easy Tier is active on one or more storage pools and summarize the activity per volume as the prior heat data file was produced. On SAN Volume Controller and Storwize V7000, the heat data file is in /dumps directory on the configuration node and is named as dpa_heat.node_name.time_stamp.data. Any existing heat data file is erased whenever a new heat data file is produced. The file needs to be off-loaded by the user and Storage Tier Advisor Tool has to be invoked from a Windows command prompt console with the file specified as a parameter. The user can also specify the output directory. The Storage Tier Advisor Tool creates a set of HTML files and the user can then open the resulting index.html file in a browser to view the results.

8 I/O workload calibration tools The Vdbench tool and the ORION tool can be used to generate Oracle-specific I/O load and to gather the resulting performance statistics. This section provides an overview and description of both the tools but. You can refer to the user guides for the tools for a complete understanding of the tools.

8.1 Vdbench overview

Vdbench generates a wide variety of controlled storage I/O workloads, allowing control over workload parameters such as I/O rate, LUN or file sizes, transfer sizes, thread count, volume count, volume skew, read/write ratios, read and write cache hit percentages, and random or sequential workloads.

There is no requirement for Vdbench to run as root as long as the user has read/write access for the target disks or file systems and for the output-reporting directory.

Nonperformance-related functionality includes data validation with Vdbench keeping track of the information regarding the nature of data and the location where it is written, allowing validation after a controlled or an uncontrolled shutdown.


8.2 ORION overview

ORION is a tool for predicting the performance of an Oracle database without having to install Oracle or create a database. Unlike other I/O calibration tools, ORION is expressly designed for simulating Oracle database I/O workloads using the same I/O software stack as Oracle. It can also simulate the effect of striping performed by ASM.

Small random I/O: OLTP applications typically generate random reads and writes whose size is equivalent to the size of the database block, which is typically 8 KB. Such applications care about the throughput in IOPS and about the average latency (I/O turnaround time) per request. These parameters translate to the transaction rate and transaction turnaround time at the application layer.

For each type of workload, ORION can run tests at different levels of I/O load to measure performance metrics such as Mbps, IOPS, and I/O latency. Load is expressed in terms of the number of outstanding asynchronous I/O. Internally, for each such load level, the ORION software issues I/O requests as fast as they complete to maintain the I/O load at that level. For random workloads (large and small), the load level is the number of outstanding I/O. For large sequential workloads, the load level is a combination of the number of sequential streams and the number of outstanding I/O per stream. Testing a given workload at a range of load levels helps the user understand how performance is affected by load.

9 Lab setup This section lists the hardware and software configurations that were used in the lab exercises.

Table 2 describes the Storwize V7000 hardware used in the exercise.

Storage name IBM Storwize V7000

Software version 6.1.0.0 (build 49.0.1010130001)

SAS disk 300 GB 1000 rpm

Solid-state drive 300 GB

Table 2: Storage information

Table 3 describes the IBM Brocade switches used in the tests.

IBM name IBM System Storage SAN 24B-4

IBM machine type 2498

IBM machine model B24

Brocade name 300

Fabric OS 6.4.0a

Table 3: FC switch information


Table 4 below describes the host node that was used for the tests.

Server type X86_64

Processor Intel(R) Xeon(R) CPU @ 2.93GHz

Memory 64 GB

Host Bus Adapter (HBA) model QLogic Corp.

Operating system Red Hat Enterprise Linux Server release 5.5 (Tikanga)

Kernel version 2.6.18-194.26.1.el5

Multipath software Linux 5 DM Multipath

Table 4: Host information

Table 5 provides the versions of both the tools that were used to generate the I/O workload.

Vdbench 5.02

ORION 11.1.0.7.0

Table 5: Workload tools version

10 Testing methodology This section describes the test methodology that was used for showing the performance benefits of the Easy Tier functionality in an IBM Storwize V7000 storage system. It provides the metrics that were collected during the Vdbench and the ORION runs and also explains the storage configuration used for the test runs.

10.1 IBM Storwize V7000 Storage configuration used for the test runs This section explains the storage configuration for the various test runs.


10.1.1 Easy Tier configuration

The Easy Tier configuration used in this test is as follows.

1. The Easy Tier storage pool included seven MDisks, where MDisk 0, MDisk1, MDisk 2, and MDisk3 consisted of HDDs while MDisk4, MDisk5, and MDisk6 consisted of solid-state drives. (Refer to Figure 21.)

Figure 21: HDD and solid-state drive MDisks in the Easy Tier storage pool

2. Each MDisk in the HDD tier had a capacity of 1.1 TB, and included eight member drives each of capacity 300 GB configured in RAID10. (Refer to Figure 22 and Figure 23.)


Figure 22: Overview of the HDD MDisk


Figure 23: Member drives in the HDD MDisk

3. Each MDisk in the solid-state drive tier had a capacity of 278.9 GB, and included two member

drives, each of capacity 300 GB configured in RAID 10. (Refer to Figure 24 and Figure 25.)


Figure 24: Overview of the solid-state drive MDisk


Figure 25: Member drives in the solid-state drive MDisk

4. Four volumes, each of capacity 500 GB, were created from the Easy Tier storage pool. (Refer to Figure 26.)

Figure 26: The four volumes used for testing Easy Tier


5. The four volumes are then mapped to the host through the FC ports. (Refer to Figure 27.)

Figure 27: Volumes mapped to the host

10.2 Linux host configuration used for the test runs

Device multipathing was configured on the Linux® host as per the instructions provided in Red Hat Enterprise Linux 5 DM Multipath DM Multipath Configuration and Administration Edition 3.

10.3 Vdbench test run description

This section describes the Vdbench tests that were run and the workload that the test had simulated.

Vdbench controls individual IOPS and workload by sending new I/O requests to each volumes internal work queue. This work queue has a maximum queue depth of 2000 per volume. The I/O threads for each volume then pick up a new request from this queue to start the I/O.

When an volume cannot keep up with it’s requested workload and the volumes internal work queue fills up, Vdbench will not generate new I/O requests for this and all other volumes until space in this queue becomes available again.

10.3.1 OLTP only

This test used 8 KB block sizes, and varying percentage combinations of reads and writes. The following combination of reads and writes were tested:

• 100% reads • 50% reads and 50% writes • 70% reads and 30% writes

The example below show the parameters that were used while running the 50% reads and 50% write test:

sd=sd1,lun=/dev/dm-0,size=500g,openflags=o_direct





wd=wd1,sd=(sd1,sd2,sd3,sd4),xfersize=8k,rdpct=50,seekpct=100

rd=run1,wd=wd1,iorate=5000,pause=60,elapsed=172800,interval=30


10.4 ORION test run description

This section describes the ORION tests that were run and the workload that the test was simulating.

10.4.1 OLTP only

The OLTP workload in ORION generated 100 percent random reads whose size is equivalent to the database block size, typically 8 KB.

The following example shows the parameters passed to ORION tool for this test.

# ./orion_linux_x86-64 -run oltp -testname mytest -simulate raid0 -cache_size=0 -duration 7200

# cat mytest.lun

/dev/mapper/mpath83

/dev/mapper/mpath84

/dev/mapper/mpath85

/dev/mapper/mpath86

11 Easy Tier test results This section describes the results from the Vdbench and Oracle ORION tests that were performed with Easy Tier enabled on the IBM Storwize V7000.

11.1 Oracle OLTP workload using Vdbench

This section describes the results of the Vdbench tests with and without Easy Tier enabled in the IBM Storwize V7000.

11.1.1 OLTP workload without Easy Tier configured

The bullets below describe the storage setup, the workload generated, and the results that were observed.

• For this test, four volumes were created on a storage pool which consisted of four HDD MDisks. Each MDisk was 1.1 TB in size, and configured using RAID 10 with 8 x 300 GB drives. The stripe size of the storage pool was 256 MB.

• The workload generated by Vdbench was 100 percent random read with 8 k block size. For this workload, the I/O rate has been fixed to 5000. The test was run for a duration of 30 hours.

• As shown in Figure 28, it has been observed that the team got around 3720 IOPS, and the response time was around 8.63 ms.


0

500

1000

1500

2000

2500

3000

3500

4000

16:5

0:01

17:5

1:31

18:5

3:01

19:5

4:31

20:5

6:01

21:5

7:31

22:5

9:01

0:00

:31

1:02

:01

2:03

:31

3:05

:01

4:06

:31

5:08

:01

6:09

:31

7:11

:01

8:12

:31

9:14

:01

10:1

5:31

11:1

7:01

12:1

8:31

13:2

0:01

14:2

1:31

15:2

3:01

16:2

4:31

17:2

6:01

18:2

7:31

19:2

9:01

20:3

0:31

21:3

2:01

22:3

3:31

test run time

iop

s

0

5

10

15

20

25

30

35

40

45

50

resp

on

se t

ime(

ms)

IOPS

Response Time(ms)

Figure 28: Base run without Easy Tier

11.1.2 OLTP workload of 100 percent random reads with Easy Tier configured

The bullets describe the storage setup, the workload generated, extent migration, and the test results observed.

• For this test, seven volumes were created on a storage pool, of which four MDisks were of HDDs and three MDisks were of solid-state drives. Each HDD MDisk was 1.1 TB in size and configured using RAID 10 with 8 x 300 GB drives. Each solid-state drive MDisk was 300 GB in size and configured using RAID10 with 2 x 300 GB drives. The stripe size of the storage pool was 256 MB.

• The workload generated by Vdbench was 100 percent random read with 8 k block size. For this workload, the I/O rate has been fixed to 5000. The test was run for a duration of 30 hours.

• As shown in Figure 29, the team observed that they got around 3720 IOPS, and the response time was around 8.63 ms during the analysis of the I/O pattern by Easy Tier. All the extents at this point were on the four MDisk with HDD drives.

• The team then observed that the hot extents of the volumes migrated from the HDD MDisks to the solid-state drive MDisks.

• After the migration of the extents, the team observed around 5640 IOPS and a response time of around 4.85 ms for the workload.


0

1000

2000

3000

4000

5000

6000

7000

8000

17:0

1:34

18:0

3:04

19:0

4:34

20:0

6:04

21:0

7:34

22:0

9:04

23:1

0:34

1:12

:04

2:13

:34

3:15

:04

4:16

:34

5:18

:04

6:19

:34

7:21

:04

8:22

:34

9:24

:04

10:2

5:34

11:2

7:04

12:2

8:34

13:3

0:04

14:3

1:34

15:3

3:04

16:3

4:34

17:3

6:04

18:3

7:34

19:3

9:04

20:4

0:34

21:4

2:04

22:4

3:34

test run time

iop

s

0

5

10

15

20

25

30

35

40

45

resp

on

se t

ime(

ms)

IOPS

Response Time(ms)

Analyze I/O Pattern & Develop Migration Plan Post Extent MigrationExtent Migration

Figure 29: Random read with Easy Tier

11.1.3 OLTP workload of 70 percent random reads and 30 percent random writes with Easy Tier configured



• The workload generated by Vdbench was 70 percent random reads and 30 percent random writes with 8 K block size .For this workload, the I/O rate has been fixed to 5000. The test was run for a duration of 30 hours.

• As shown in Figure 30, the team observed that they got around 4000 IOPS, and the response time was around 8.00 ms during the analysis of the I/O pattern by Easy Tier. All the extents at this point were on the the MDisk with HDDs.

• The team then observed that the hot extents of the volumes migrated from the HDD MDisks to the solid-state drive MDisks.


• After the migration of the extents, the team observed around 5414 IOPS and a response time of

around 3.88 ms for the workload.

0

1000

2000

3000

4000

5000

6000

7000

8000

2:39

:35

4:22

:05

6:04

:35

7:47

:05

9:29

:35

11:1

2:05

12:5

4:35

14:3

7:05

16:1

9:35

18:0

2:05

19:4

4:35

21:2

7:05

23:0

9:35

0:52

:05

2:34

:35

4:17

:05

5:59

:35

7:42

:05

9:24

:35

11:0

7:05

12:4

9:35

14:3

2:05

16:1

4:35

17:5

7:05

19:3

9:35

21:2

2:05

23:0

4:35

0:47

:05

2:29

:35

test run time

iop

s

0

5

10

15

20

25

30

35

40

resp

on

se t

ime(

ms)

IOPS

Response Time(ms)

Analyze I/O Pattern& Develop Migration Plan Extent Migration Post Extent Migration

Figure 30: A graphical representation indicating 70 percent reads and 30 percent writes with Easy Tier

11.1.4 OLTP workload of 50 percent random reads and 50 percent random writes with Easy Tier configured



• The workload generated by Vdbench was 50 percent random reads and 50 percent random writes with 8 K block size .For this workload, the I/O rate has been fixed to 5000. The test was run for a duration of 30 hours.

• As shown in Figure 31, the team observed that they got around 4342 IOPS and the response time was around 7.39.ms during the analysis of the I/O pattern by Easy Tier. All the extents at this point were on the four MDisk with HDDs.


• The team then observed that the hot extents of the volumes migrated from the HDD MDisks to

the solid-state drive MDisks.

• After the migration of the extents, the team observed around 5000 IOPS and a response time of around 3.00 ms for the workload.

0

1000

2000

3000

4000

5000

6000

7000

80001:

30:2

5

3:12

:55

4:55

:25

6:37

:55

8:20

:25

10:0

2:55

11:4

5:25

13:2

7:55

15:1

0:25

16:5

2:55

18:3

5:25

20:1

7:55

22:0

0:25

23:4

2:55

1:25

:25

3:07

:55

4:50

:25

6:32

:55

8:15

:25

9:57

:55

11:4

0:25

13:2

2:55

15:0

5:25

16:4

7:55

18:3

0:25

20:1

2:55

21:5

5:25

23:3

7:55

1:20

:25

test run time

iop

s

0

5

10

15

20

25

30

resp

on

se t

ime(

ms)

IOPS

Response Time(ms)

Analyse I/O Pattern Extent Migration Post Extent Migration

Figure 31: A graphical representation indicating 50 percent reads and 50 percent writes with Easy Tier

11.2 Oracle OLTP workload using ORION

OLTP applications generate small random I/O where the size is equivalent to the database block size, typically 8 KB.

For the Oracle ORION OLTP read-only workload IOPS and latency are reported. As shown below the performance metrics are displayed as graphs where the y-axis reports the number of IOPS or the latency in milliseconds (ms), while the x-axis reports the workload value. In Oracle ORION the workload is represented by the number of outstanding asynchronous I/O. Orion issues asynchronous I/O requests at an increasing rate and then measures performance metric values for each workload.

11.2.1 OLTP workload without Easy Tier configured

For this test, four MDisks were created on a storage pool, the four MDisks were HDDs drives. Each HDD MDisk was 1.1 TB in size and configured using RAID 10 with 8 x 300 GB drives. Four 500 GB volumes were created and presented to the host from the storage pool. The stripe size of the storage pool was 256 MB.


We observed that for this with 21 outstanding asynchronous we got 6109 IOPS. We also observed that at a sustained load level of 21 outstanding small reads, we got an I/O turn around time of 13.09 ms.

The graph below was generated by loading the iops.csv generated at the end of ORION run into Excel and charting the data, illustrates the IOPS seen at different small I/O load levels.

IOPS

0

1000

2000

3000

4000

5000

6000

7000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

outstanding asynchronous i/o

iop

s

IOPS

Figure 32: Oracle ORION IOPS result for an OLTP workload without Easy Tier configured

A comma-separated value file containing the latency results for the small random workload is generated at the end of the test. The graph in Figure illustrates the small I/O latency at different small I/O load level for the test.


Latency

0

2

4

6

8

10

12

14

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

outstanding asynchronous I/O

late

ncy

(ms)

Latency(ms)

Figure 33: Oracle ORION Latency result for an OLTP workload without Easy Tier configured

11.2.2 OLTP workload with Easy Tier configured

For this test, seven MDisks were created on a storage pool, of which four MDisks were of HDDs and three MDisks were of solid-state drives. Each HDD MDisk was 1.1 TB in size and configured using RAID 10 with 8 x 300 GB drives. Each solid-state drive MDisk was 300 GB in size and configured using RAID10 with 2 x 300 GB drives. The stripe size of the storage pool was 256 MB.

We observed that after analyzing the I/O pattern Easy Tier migrated the hot extents of the volumes from the HDD MDisks to the solid-state drive MDisks.

We also observed that with 21 outstanding asynchronous we got 10713 IOPS. We also observed that at a sustained load level of 21 outstanding small reads, we got an I/O turn around time of 7.47 ms.

The graph below was generated by loading the iops.csv generated at the end of ORION run into Excel and charting the data, illustrates the IOPS seen at different small I/O load levels.


IOPS

0

2000

4000

6000

8000

10000

12000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21


iop

s

IOPS

Figure 34: Oracle ORION IOPS result for an OLTP workload with Easy Tier configured

Comma-separated value file containing the latency results for the small random workload is generated at the end of the test. The graph in Figure illustrates the small I/O latency at different small I/O load level for the test.


Latency

0

2

4

6

8

10

12

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21


late

ncy

(ms)

Latency(ms)

Figure 35: Oracle ORION Latency result for an OLTP workload with Easy Tier configured

12 Summary We observed that there is no need for manually tuning the storage to see the performance benefits, as Easy Tier takes care of it automatically. In the paper we have also observed the ease at which Easy Tier can be configured and deployed.

With Tier Advisor and Easy Tier, the users are now be able provision SSDs accurately for their Oracle workloads. The Storage Tier Advisor Tool provides a high-level summary of workload characteristics and hot extents of the volumes that are monitored. It also provides assistance for SSD capacity planning with Easy Tier. When Easy Tier is enabled it observes the I/O pattern, and then migrates the data from the HDD MDisks to the SSD MDisks non-disruptively.

This combination of Easy Tier and The Storage Tier Advisor Tool provides a high impact, combined with low investment of efforts for the end user.


Resources The following websites provide useful references to supplement the information contained in this paper:

• Deploying Oracle 11g RAC Release 2 with IBM Storwize V7000 on Red Hat Enterprise Linux

ibm.com/support/techdocs/atsmastr.nsf/WebIndex/WP101772

• Practice guide: Backup and restore of native Oracle Database solutions using IBM Tivoli Flashcopy Manager Version 1.0


• IBM SAN Volume Controller Performance Configuration Guidelines for Implementing Oracle Databases with Automatic Storage Management (ASM)


• IBM Business Partner support and resources ibm.com/partnerworld/pwhome.nsf/weblook/index_us.html

• IBM Publications Center www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi?CTY=US

• IBM Redbooks® ibm.com/redbooks

• IBM developerWorks® ibm.com/developerWorks


Trademarks and special notices © Copyright IBM Corporation 2011. All rights Reserved.

References in this document to IBM products or services do not imply that IBM intends to make them available in every country.

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at www.ibm.com/legal/copytrade.shtml.

Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates.

Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Intel, Intel Inside (logos), MMX, and Pentium are trademarks of Intel Corporation in the United States, other countries, or both.

UNIX is a registered trademark of The Open Group in the United States and other countries.

Linux is a trademark of Linus Torvalds in the United States, other countries, or both.

SET and the SET Logo are trademarks owned by SET Secure Electronic Transaction LLC.

DIA Data Integrity Assurance®, Storewiz®, Storwize®, and the Storwize® logo are trademarks or registered trademarks of Storwize, Inc., an IBM Company.

Other company, product, or service names may be trademarks or service marks of others.

Information is provided "AS IS" without warranty of any kind.

All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual environmental costs and performance characteristics may vary by customer.

Information concerning non-IBM products was obtained from a supplier of these products, published announcement material, or other publicly available sources and does not constitute an endorsement of such products by IBM. Sources for non-IBM list prices and performance numbers are taken from publicly available information, including vendor announcements and vendor worldwide homepages. IBM has not tested these products and cannot confirm the accuracy of performance, capability, or any other claims related to non-IBM products. Questions on the capability of non-IBM products should be addressed to the supplier of those products.

All statements regarding IBM future direction and intent are subject to change or withdrawal without notice, and represent goals and objectives only. Contact your local IBM office or IBM authorized reseller for the full text of the specific Statement of Direction.


Some information addresses anticipated future capabilities. Such information is not intended as a definitive statement of a commitment to specific levels of performance, function or delivery schedules with respect to any future products. Such commitments are only made in IBM product announcements. The information is presented here to communicate IBM's current investment and development activities as a good faith effort to help with our customers' future planning.

Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput or performance that any user will experience will vary depending upon considerations such as the amount of multiprogramming in the user's job stream, the I/O configuration, the storage configuration, and the workload processed. Therefore, no assurance can be given that an individual user will achieve throughput or performance improvements equivalent to the ratios stated here.

Photographs shown are of engineering prototypes. Changes may be incorporated in production models.

Any references in this information to non-IBM websites are provided for convenience only and do not in any manner serve as an endorsement of those websites. The materials at those websites are not part of the materials for this IBM product and use of those websites is at your own risk.

performance benefits of ibm storwize v7000 with easy · pdf fileperformance benefits of ibm...

Documents