Docu48440 White Paper Optimizing Application Performance Using VMAX Host I O Limits for DB2 for Linux, Unix, And Windows

8/13/2019 Docu48440 White Paper Optimizing Application Performance Using VMAX Host I O Limits for DB2 for Linux, Unix, A

1/43


2/43

2Optimizing application performance using Symmetrix VMAX Host I/O limits forDB2 for Linux, Unix, and Windows

Copyright 2013 EMC Corporation. All Rights Reserved.

EMC believes the information in this publication isaccurate as of its publication date. The information is

subject to change without notice.

The information in this publication is provided as is.EMC Corporation makes no representations orwarranties of any kind with respect to the informationin this publication, and specifically disclaims impliedwarranties of merchantability or fitness for a particularpurpose.

Use, copying, and distribution of any EMC softwaredescribed in this publication requires an applicable

software license.

For the most up-to-date listing of EMC product names,see EMC Corporation Trademarks on EMC.com.

All other trademarks used herein are the property oftheir respective owners.

Part Number H11981


3/43


Table of Contents

Executive summary.................................................................................................. 5

Audience................................................................................................................. 6

Introduction ............................................................................................................ 7

VMAX Host I/O Limits Architecture Overview ............................................................ 7 Cascaded Host I/O Limits ................................................................................................... 8 Dynamic distribution ........................................................................................................ 11 Dynamic distribution modes ............................................................................................. 12 Protocols supported ......................................................................................................... 12 Configuration Overview .................................................................................................... 12

Host I/O Limits with Solutions Enabler ......................................................................... 12 Host I/O Limits with Unisphere ..................................................................................... 15

Limitations, Scalability and General Restrictions .............................................................. 18

Test case scenarios of Host I/O Limits with IBM DB2 for LUW .................................. 21 Test case 1: Using Host I/O Limits to minimize the impact of Tier 2 applications onTier1 applications sharing the same VMAX storage infrastructure ........................................ 21

Functional overview:..................................................................................................... 22 Hardware Configuration:............................................................................................... 22 Software Stack: ............................................................................................................ 23 Test Results: ................................................................................................................. 27

Test case 2 : Using cascaded Host I/O Limits to reconfigure developmentenvironment with no impact to Production ....................................................................... 28

Functional Overview: .................................................................................................... 29 Hardware Configuration:............................................................................................... 29 Software Stack: ............................................................................................................ 30 Test Results: ................................................................................................................. 33

Test case 3 : Use Dynamic Host I/O Limits feature to redistribute and failoverHost I/O Limits to online FA directors ................................................................................ 34

Functional Overview: .................................................................................................... 34 Hardware Configuration: ............................................................................................... 34 Software Stack: ............................................................................................................. 35 Test Results: ................................................................................................................. 36

Test case 4: Use Dynamic Host I/O Limits feature to redistribute and failoverHost I/O Limits to online FCoE directors ............................................................................ 38

Functional Overview: .................................................................................................... 38 Hardware Configuration:............................................................................................... 39 Software Stack: ............................................................................................................ 39 Test Results: ................................................................................................................. 40

Conclusion ............................................................................................................ 42


4/43


References ............................................................................................................ 43


5/43


Executive summary

In a multi-tenant environment, storage infrastructure is shared among a variety ofservers and applications. Whenever an application overloads the storage in suchan environment, it can affect other applications sharing that storageinfrastructure, leading to resource contention and reduced performance for criticalapplications. As organizations grow and scale, their storage infrastructure alsogrows. Consequently, the need for a way, to enforce performance boundariesbetween applications sharing the storage, is greater than ever. This enforcementof performance boundaries is necessary to maintain service level agreements forall applications or tenants.

The EMC Symmetrix VMAX Host I/O Limits feature addresses this concern byproviding a way to set the desired IOPS and bandwidth limits at the storage grouplevel; these storage groups can then be associated with a set of front end VMAXports through the provisioning of a masking view. This enables organizations tomaintain their service level agreements and ensure that each application is ableto maintain a predictable level of performance without adversely affecting othersand still share the same VMAX storage system.

This white paper demonstrates use cases of the VMAX Host I/O Limits feature withIBM DB2 for Linux, Unix, and Windows (DB2 for LUW) databases. It coversapplication performance optimization using Host I/O Limits, cascaded Host I/OLimits with Dynamic distribution, support over both Fibre Channel, and FibreChannel over Ethernet environments.


6/43


Audience

The white paper is intended for database administrators, storage administrators,architects, EMC customers, EMC field personnel and technology professionals whowant to understand the management of the performance of DB2 for LUW databasesusing the VMAX Host I/O Limits feature of EMC VMAX arrays in a multi-tenant

environment.


7/43


Introduction

VMAX Host I/O Limits, is a feature introduced in Solutions Enabler 7.5 andEnginuity 5876 Q4 2012 SR that puts a limit on the amount of Front EndBandwidth and Input/ Output operations per second (IOPS) that can be utilizedby a set of Symmetrix devices over a set of front end director ports. This featureallows for Symmetrix resources to be shared between all the tenants on a VMAXstorage system that are on the same port group, but ensures that each tenant hasits own workload and bandwidth level, which is set based on service levels andperformance requirements. Essentially, this feature enables the applications ortenants sharing a VMAX storage system to consume logically separate VMAXperformance resources.

The test case scenarios and detailed implementation procedures provideddemonstrate the use of VMAX Host I/O Limits with IBM DB2 for LUW on AIX andWindows servers using Fibre Channel and FCoE adapters, as well as illustratehow the Host I/O Limits feature can be utilized to clear performance bottlenecksin a multi-tenant storage environment.

VMAX Host I/O Limits Architecture Overview

Host I/O Limits enables users to set limits on the workload and bandwidth oftheir applications; this, in turn, enables many applications to coexist,maintaining their performance boundaries in a secure fashion. VMAX autoprovisioning groups prevents any tenant from accessing another tenants data.Using auto provisioning groups, each application can create its own maskingview but share the port group. This allows them to share VMAX resources on thefront end adapter (FA) ports while at the same time the traffic on the FA ports iscontrolled by the Host I/O Limits setting on the applications storage group.

Masking views associates a group of host initiators (called an initiator group), agroup of front end director ports (called a port group) and a group of devices(called a storage group). Creating a masking view is a simple operation andconsolidates the mapping and masking into one operation. Any initiators, portsor devices added to an existing group are automatically added to the appropriatemasking view.


8/43


9/43


child storage group are limited only by the child Host I/O Limits. In a cascadedscenario, the Host I/O Limits can be oversubscribed, that is, the total Host I/OLimits of the children can be greater than the Host I/O Limit set at the parentlevel. However, the Host I/O Limits set on any of the child storage groups cannotexceed the limits set on the parent. The number of child Host I/O Limits and theirratios to each other, and to the parent, along with the number of children

exceeding their Host I/O Limits are key determinants in deciding how the HostI/O Limits are distributed in oversubscribed situations.

Figure 2 shows a masking view created at parent storage group level.

P o r t g r o u p

I n i t i a

o r g r o u p

Parent SG

Child SG

Child SG

Child SG

t Masking View

Host I/OLimits

Host I/OLimits

Host I/OLimits

Host I/OLimits

Figure 2 Masking view created on the Parent Storage Group

A parent Host I/O Limits can have multiple child Host I/O Limits attached to it;however, the converse is not true. A child Host I/O Limit can be linked to only oneparent Host I/O Limit. A child Host I/O Limit inherits the parent Host I/O Limitsettings if no settings are defined and will show up as being Shared. A childcan have a different Host I/O Limit setting than its parent; in such cases, the HostI/O Limit for the child will show up as Defined.

In the following example, Parents Host I/O Limit is set at 10,000 iops, Child1sHost I/O Limit is set at 4,000 iops and Child2s Host I/O Limit is not set. We seethat Child1 has its own Host I/O Limit and shows the setting asDefined(Shared) and Child2 inherits the Parents Host I/O Limit and shows thesetting as Shared.

# symsg -sid 351 show Parent_stor

Name: Parent_stor

Symmetrix ID : 000195700351Last updated at : Tue May 21 15:21:50 2013Masking Views : Yes


10/43


FAST Policy : NoHost I/O Limit : Defined Host I/O Limit MB/Sec : NoLimitHost I/O Limit IO/Sec : 10000Dynamic Distribution : AlwaysNumber of Storage Groups : 3

Storage Group Names : Child1_stor (IsChild)Child2_stor (IsChild)Child3_stor (IsChild)

Devices (3):{---------------------------------------------------------Sym Device CapDev Pdev Name Config Sts (MB)---------------------------------------------------------060B N/A TDEV RW 983040

0617 N/A TDEV RW 983040061B N/A TDEV RW 983040}

# symsg -sid 351 show Child1_stor

Name : Child1_stor

Symmetrix ID : 000195700351Last updated at : Mon Apr 22 13:27:58 2013Masking Views : Yes

FAST Policy : NoHost I/O Limit : Defined (Shared) Host I/O Limit MB/Sec : NoLimit (NoLimit)Host I/O Limit IO/Sec : 4000 (10000)Dynamic Distribution : AlwaysNumber of Storage Groups : 1Storage Group Names : Parent_stor (IsParent)

Devices (1):{---------------------------------------------------------

Sym Device CapDev Pdev Name Config Sts (MB)---------------------------------------------------------060B N/A TDEV RW 983040}

# symsg -sid 351 show Child2_stor


11/43


Name : Child2_stor

Symmetrix ID : 000195700351Last updated at : Mon Apr 29 15:05:54 2013Masking Views : Yes

FAST Policy : NoHost I/O Limit : Shared Host I/O Limit MB/Sec : NoLimitHost I/O Limit IO/Sec : 10000Dynamic Distribution : AlwaysNumber of Storage Groups : 1Storage Group Names : Parent_stor (IsParent)

Devices (1):{---------------------------------------------------------

Sym Device CapDev Pdev Name Config Sts (MB)---------------------------------------------------------061B N/A TDEV RW 983040}

Dynamic distribution

The dynamic distribution of Host I/O Limits can be set across configured director

ports in a port group. This allows for the Host I/O Limit allocation on eachindividual port to adjust to fluctuating demand. In the absence of dynamicdistribution, each front end director in the port group is allocated a fixed value ofHost I/O Limits and these limits remain the same, regardless of whether otherfront end directors in the port group are online or offline. For example, if the HostI/O Limit is 10,000 IOPS and there are two directors in the port group, eachdirector will be assigned a static (fixed) 5,000 Host I/O Limit.


12/43


It is important to note that Host I/O Limits need to set up on a storage groupbefore dynamic distribution can be enabled on the group.

Dynamic distribution modes

Host I/O Limits are shared between the front end directors to which storagegroups are mapped and the redistribution of Host I/O Limits is provided based oncustomer requirements. Some customers prefer redistribution of Host I/O Limitsamong director ports and some prefer that if a director has failed, the unusedHost I/O Limit to be failed over to the remaining online directors. Accordingly,three settings are available OnFailure, Always, and Never. The settingOnFailure enables the Host I/O Limit to failover when one of the front enddirector ports in a port group fails. OnFailure causes the fraction of Host I/OLimits to be adjusted among the online ports if any of the ports in the port groupgo offline. OnFailure is a subset of Always. Always enables the Host I/OLimit to be distributed evenly in all kinds of situations, such as when a front end

director fails, a director is added, or a director is removed. Always allows forthe configured Host I/O Limits to be dynamically distributed across theconfigured ports. The redistribution is dynamic and seamless. Once the offlinedirector comes back online, the Host I/O Limit is again redistributed across allthe ports. The default setting is Never which means that dynamic distribution isdisabled and no dynamic distribution setting is available for the storage group. Inthis case, the dynamic distribution flag has to be explicitly enabled.

Protocols supported

This feature is supported on Front-End ports for Fibre Channel, iSCSI and FCoEdirectors. It is not currently supported for FICON.

Configuration Overview

Host I/O Limits with Solutions Enabler

1. Setting up Host I/O Limits

Host I/O Limits can be set either in a single or cascaded level. The symsg setcommand is used to allow Host I/O Limits to be set on a Storage Group(SG). TheStorage group needs to be assigned to a masking view for the Host I/O Limits tofunction.

symsg sid -sg set iops_max


13/43


14/43


Figure 3 below shows the Host I/O Limits demand on the front end director ports .

Figure 3 Host I/O Limits on the Front end Directors

The symsg list by_pg demand command shows the demand report for all ofthe port groups.

symsg sid list by_pg demand

5. Removing Host I/O Limits

Setting the Host I/O Limit to NOLIMIT removes the Host I/O Limits set on a storagegroup

symsg sid -sg set iops_max NOLIMIT

The symsg remove command will allow a SG with Host I/O Limits to be removedfrom a parent SG that is in a masking view.

symsg sid -sg remove sg


15/43


Host I/O Limits with Unisphere

1. Setting up Host I/O Limits

Check the Host I/O Limits checkbox, and depending on whether setting Limits atthe IOPs level or the throughput level, enter the respective values.

Figure 4 shows how to set Host I/O Limits on Unisphere.

Figure 4 Set Host I/O Limits

2. Activating Host I/O LimitsHost I/O Limits can be activated by creating a masking view on the storage group onwhich the Host I/O Limits are set.


16/43


Figure 5 shows how to create a masking view on Unisphere, which in turn activatesthe Host I/O Limits set on the storage group.

Figure 5 Activate Host I/O Limits

3. Set dynamic distribution

Select the appropriate dynamic distribution option from the drop down menuprovided for the Set dynamic distribution field.

Figure 6 shows how to set dynamic distribution of Host I/O Limits on Unisphere.

Figure 6 Set Dynamic distribution of Host I/O Limits


17/43


4. Port group demandThe Port details window lists the port group demand.

Figure 7 shows the Host I/O Limits demand on the Port Group in Unisphere window.

Figure 7 Port Group demand Report

5. Removing Host I/O LimitsUncheck the appropriate Host I/O Limits checkbox MB/sec or IO/sec,

whichever is set.

Figure 8 shows how to remove Host I/O Limits in Unisphere.

Figure 8 Remove Host I/O Limits


18/43


Limitations, Scalability and General Restrictions

There is a maximum of 2048 Host I/O Limits configurable on a single VMAX. Forcascaded Host I/O Limits, there can a maximum of 32 child Host I/O Limits in aparent .

When setting up Host I/O Limits, the following restrictions apply.

Creating a masking view on a child storage group is not allowed if the childsparent storage group has an FE Host I/O Limit defined.

# symaccess-sid 351 create view -name test_view -ig lfqu1063_ig -pglfqu1063_port -sg lfqu1231_child_vm1

Error: Cannot perform the requested operation because the group is currentlywithin a masking view or a masking view through cascading.

At any given time, a storage group with an FE Host I/O Limit can be associatedwith at most one port group in any masking view. This means if a storage group witha front end Host I/O Limit is in a masking view with a port group, the storage groupand port group combination have to be used when creating other masking views onthe storage group. If the user tries to create a masking view using a different portgroup, an error will be returned.

# symaccess-sid 351 create view -name lfqu1063_pg_view -ig lfqu1063_ig -pgpg_6e1_9e1 -sg lfqu1063_p_vm_stor

Error: The operation cannot be performed because the storage group with a HostI/O Limit can be associated with at most one port group in any masking view


19/43


Any device can be in at most one storage group with front end Host I/O Limits. Ifan attempt is made to add the same device to other storage groups with front endHost I/O Limits, an error will be returned.

# symaccess -sid 351 -name lfqu1231_child_vm1 -type stor -dev 61b add

Error: The operation cannot be performed because the device already exists in astorage group with a Host I/O Limit

The parent and child storage groups must have the same Dynamic Distributionattribute value before they can be placed in a cascaded relationship.

In the following example, the Parent storage group has a setting a Always andtrying to set OnFailure on the child fails.

# symsg -sid 351 show lfqu1063_p_vm_stor

Name: lfqu1063_p_vm_stor

Symmetrix ID : 000195700351Last updated at : Tue May 21 15:21:50 2013Masking Views : YesFAST Policy : NoHost I/O Limit : DefinedHost I/O Limit MB/Sec : NoLimitHost I/O Limit IO/Sec : 10000Dynamic Distribution : Always Number of Storage Groups: 3Storage Group Names : lfqu1231_child_vm1 (IsChild)

lfqu2048_child_vm2 (IsChild)lfqu2049_child_vm3 (IsChild)

Devices (3):{---------------------------------------------------------Sym Device CapDev Pdev Name Config Sts (MB)---------------------------------------------------------060B N/A TDEV RW 983040


20/43


0617 N/A TDEV RW 983040061B N/A TDEV RW 983040}

# symsg -sid 351 -sg lfqu1231_child_vm1 set -dynamic always

Error: The operation cannot be performed because the storage group attributeconflicts with other parent or child storage group attribute


21/43


Test case scenarios of Host I/O Limits with IBM DB2 for LUW

The following use cases were implemented:

Test case 1: Using Host I/O Limits to minimize the impact of Tier 2 applications onTier1 applications sharing the same VMAX storage infrastructure

Test case 2: Using cascaded Host I/O Limits to reconfigure development environmentwith no impact to Production

Test case 3: Using Dynamic Host I/O Limits feature to redistribute and failover HostI/O Limits to online FA directors when one or more directors go offline

Test case 4: Using Dynamic Host I/O Limits feature to redistribute and failover HostI/O Limits to online FCoE directors when one or more directors go offline

Test case 1: Using Host I/O Limits to minimize the impact of Tier 2applications on Tier1 applications sharing the same VMAX storageinfrastructure

This section shows two applications sharing the same VMAX port group but having

their own storage groups and masking views. By Limiting the IOPS on one, more frontend ports resources are available to the other resulting in a better performance.


22/43


Functional overview:

Figure 9 shows DB2 for LUW databases, App A and App B sharing the same port groupand Host I/O Limits are applied on App B.

Figure 9 DB2 UDB databases App A and App B sharing VMAX storage

The Environment consisted of a T1 (tier 1) DB2 9.7 for LUW database and aT2 (tier 2) DB2 9.7 for LUW database sharing the same FA ports and storage in thesame VMAX. By putting Host I/O Limits on the T2 application, the performance of T1 isexpected to increase in terms of IOPS and database performance. The FA resourcesare shared between the two applications with reference to CPU and memory. WhenHost I/O Limits are put on the T2 application, it enables more FA resources to bereleased for use to cater to the T1 application.

Hardware Configuration:

Host AIX232 AIX123 Model IBM 8202-E4C IBM 9110-51A

Processor PowerPC_POWER7 PowerPC_POWER5 Memory 23424 MB 3920 MB

Storage Array Symmetrix VMAX40K Symmetrix VMAX40K

Disk FC 15K rpm 450 GB

drives FC 15K rpm 450 GB

drives Protocol Fibre Channel Fibre Channel


23/43


Software Stack:

Host AIX232 AIX123Business

Importance T1 T2Databases AIX_232 ( App A) AIX_123 ( App B)

O/S AIX 7.1 AIX 6.1File system JFS2 JFS2

DB2 UDB version 9.7.3 9.7.3VMAX Enginuity 5876.229.145 5876.229.145

Multipathing Powerpath 5.5 P 02 Powerpath 5.5 P 02Storage Group lfqu1232_db2_stor lfqu1123_db2_stor

The configuration consisted of AIX P7server (T1) with DB2 for LUW and AIX P5 server(T2) running DB2 for LUW sharing the same VMAX FA ports. The DB2 databases, each

23 GB in size, were created on top of the JFS2 file system and AIX LVM, which wascreated from 8 underlying thin devices. Benchmark workload was run on thedatabases with 50 users. The benchmark test measures the ability of the system toprocess the most queries in the least amount of time in a multi-user environment. Thebenchmark test runs mainly read queries, runs multiple transactions with each onerunning independently on a specified number of users.

The AIX layout for the DB2 database is shown in Figure 10.

Physical Volumes

Volume Group

Logical Volumes

Filesystem

DB2 Database

AIX Layout

Figure 10 AIX DB2 UDB Layout


24/43


The Physical volumes were created from the eight Symmetrix devices in the Storagegroup. Each server had Powerpath installed and multiple paths to the devices wereavailable (shown in Figure 11 ).

Figure 11 AIX Powerpath Pseudo devices

Logical volumes were created on top of the volume group( shown in Figure 12 ) and ajfs2 file system was laid on top of the logical volumes. Finally, a DB2 for LUWdatabase was created on top of the jfs2 file system.

Figure 12 AIX Logical Volume

The following procedure was followed:

Ran a baseline benchmark workload with 50 users on the DB2 Databases on thetwo AIX machines with no Host I/O Limits set on them. The IOPS was measuredusing Solutions Enabler symstat commands and the response time wasmeasured using SPA.

Set a Host I/O Limit of 5000 iops on the App B database (Tier 2) storage group.The IOPS and response were measured in a similar manner.


25/43


AIX App A Storage group (Tier 1)

# symsg -sid 351 show lfqu1232_db2_stor

Name: lfqu1232_db2_stor

Symmetrix ID : 000195700351Last updated at : Tue Apr 02 10:19:35 2013Masking Views : YesFAST Policy : NoHost I/O Limit : NoneHost I/O Limit MB/Sec : N/AHost I/O Limit IO/Sec : N/ADynamic Distribution : N/A

Number of Storage Groups : 0

Storage Group Names : N/A

Devices (8):{---------------------------------------------------------Sym Device CapDev Pdev Name Config Sts (MB)---------------------------------------------------------0482 N/A TDEV RW 2447360483 N/A TDEV RW 2447360484 N/A TDEV RW 244736

0485 N/A TDEV RW 2447360486 N/A TDEV RW 2447360487 N/A TDEV RW 2447360488 N/A TDEV RW 2447360489 N/A TDEV RW 244736}


26/43


Set Host I/O Limits on AIX App B

#symsg -sid 351 -sg lfqu1123_db2_stor set -iops_max 5000

AIX App B Storage group after Host I/O Limits are set


Symmetrix ID : 000195700351Last updated at : Thu Apr 11 12:55:55 2013Masking Views : YesFAST Policy : NoHost I/O Limit : DefinedHost I/O Limit MB/Sec : NoLimitHost I/O Limit IO/Sec : 5000Dynamic Distribution : Never

Number of Storage Groups : 0Storage Group Names : N/A

Devices (8):{---------------------------------------------------------Sym Device CapDev Pdev Name Config Sts (MB)---------------------------------------------------------049A N/A TDEV RW 244736049B N/A TDEV RW 244736049C N/A TDEV RW 244736049D N/A TDEV RW 244736049E N/A TDEV RW 244736049F N/A TDEV RW 24473604A0 N/A TDEV RW 24473604A1 N/A TDEV RW 244736

}


27/43


Test Results:

APP A APP BHost I/O

Limitsapplied

IOPS Average I/OResponse time

Host I/OLimits

appliedIOPS Average I/OResponse time

No 12600 22 ms No 9000 9 msNo 18000 12.5 ms Yes 5000 16.5 ms

The Read and write response times of App A (Tier 1) decreases when the Host I/OLimits is applied on the Storage Group of App B (Tier 2).

The IOPS on App A (Tier 1) show an increase from 12600 to 18000 after Host I/OLimits applied on the storage group of App B.

12600

18000

9000

5000

0

5000

10000

15000

20000

WithoutHost I/O

Limits

WithHost I/O

Limitsapplied

to App B

IOPS

App A IOPS Increases

App A

App B

22

12.59

16.5

0

5

10

15

20

25

WithoutHost I/O

Limits

With HostI/O Limitsapplied to

App B

R e s p o n s e t i m e i n m

s

App A Response time Decreases

App A

App B


28/43


Test case 2 : Using cascaded Host I/O Limits to reconfiguredevelopment environment with no impact to Production

This section shows a cascaded set up of Host I/O Limits on ESXi server with eachVirtual machine having a storage group which is a member of the parent storagegroup. The effect of development servers affecting the Mission critical apps on thesame FA ports can be managed by having the development servers in a cascadedparent SG which has a Host I/O Limit set. In this test case, an ESXi server is taken asan example of development environment. Multiple Virtual machines running DB2 forLUW on Windows guests on the same ESX server can have their individual Host I/OLimits set as per their requirements. More development servers can be introduced byvarying the Host I/O Limits at any time.


29/43


Functional Overview:

Figure 13 shows a cascaded Host I/O Limits setup where a third virtual machine is addedto being an existing setup.

Figure 13 Cascaded Host I/O Limits setup for Test Case 2

The test cases focus was to understand the ability for front-end performance controlsto be cascaded and allocated to children storage groups. If the Production server is

on the same front end ports as a development environment, increasing the number ofdevelopment servers may impact the Production performance. But, with the help ofHost I/O Limits, performance controls can be set on the development environment sothat it doesnt affect Production. The Host I/O Limits of each database can beadjusted for optimum performance and more virtual machines can be introduced intothe existing setup without affecting the performance of the Production server.


Model Proliant BL685c G1

Processor Dual-Core AMD Opteron Processor8218Memory 65533 MB

Storage Array Symmetrix VMAX40KDisk FC 15K rpm 450 GB drives

Protocol Fibre Channel


30/43


Software Stack:

HostESX Server

lfqu1063( Parent)VM lfqu1231

( Child1)VM lfqu2048

(Child2)VM lfqu2049

(Child3)Storagegroup

lfqu1063_p_vm_stor

lfqu1231_child_vm1

lfqu2048_child_vm2

lfqu2049_child_vm3

Storagegroup type cascaded child child child

O/S ESXi 5.0Windows 2008 R2

GuestWindows 2008 R2

GuestWindows 2008 R2

GuestDB2 UDBdatabase App A App B App CDB2 UDBversion 9.7.3 9.7.3 9.7.3VMAX

Enginuity 5876.229.145 5876.229.145 5876.229.145 5876.229.145

MultipathingPowerpath VE 5.7

(build 173)Powerpath VE 5.7



(build 173)

VM DiskAccess RDM RDM RDM RDM

Host I/OLimits setting

(in iops) 10000 4000 3000 3000Host I/O

Limits type cascaded child child child

The test configuration had two virtual machines each running DB2 for LUW 9.7.3 onWindows 2008 O/S and on separate storage groups, both of which were members of acascaded storage group of an ESXi 5.0 server hosting these virtual machines. A thirdvirtual machine having DB2 for LUW on Windows 2008 was introduced into the setupsuch that the total Host I/O Limits set on the cascaded storage group did not change.A benchmark workload was run on the databases with 50 users. The baseline test wasrunning with just two virtual machines and two DB2 databases with Host I/O Limits of5000 IOPS each set on them. Then their Host I/O Limits were changed to 4000 and3000 IOPS. A third virtual machine with DB2 database and a storage group with 3000IOPS Host I/O Limit was added as a child to the parent storage group of the ESX server.The parent storage group had a Host I/O Limit of 10000 IOPS set on it.

Figure 14 shows a VMware snapshot showing the ESXi server(Parent storage group)and the virtual machines(child storage groups).


31/43


Figure 14 Vcenter snapshot showing ESX server and virtual machines

Parent Storage group

# symsg -sid 351 show lfqu1063_p_vm_stor

Name: lfqu1063_p_vm_stor

Symmetrix ID : 000195700351Last updated at : Tue May 21 16:13:13 2013Masking Views : YesFAST Policy : NoHost I/O Limit : DefinedHost I/O Limit MB/Sec : NoLimitHost I/O Limit IO/Sec : 10000Dynamic Distribution : Always

Number of Storage Groups : 3Storage Group Names : lfqu1231_child_vm1 (IsChild)

lfqu2048_child_vm2 (IsChild)lfqu2049_child_vm3 (IsChild)

Devices (3):{---------------------------------------------------------Sym Device CapDev Pdev Name Config Sts (MB)---------------------------------------------------------060B N/A TDEV RW 9830400617 N/A TDEV RW 983040061B N/A TDEV RW 983040}


32/43


Set Host I/O Limit on Child Storage group

# symsg -sid 351 -sg lfqu1231_child_vm1 set -iops_max 4000

Child Storage group

# symsg -sid 351 show lfqu1231_child_vm1

Name: lfqu1231_child_vm1

Symmetrix ID : 000195700351Last updated at : Mon Apr 22 14:19:51 2013Masking Views : YesFAST Policy : NoHost I/O Limit : Defined (Shared)Host I/O Limit MB/Sec : NoLimit (NoLimit)Host I/O Limit IO/Sec : 4000 (10000)Dynamic Distribution : Always

Number of Storage Groups: 1Storage Group Names : lfqu1063_p_vm_stor (IsParent)

Devices (1):{---------------------------------------------------------Sym Device CapDev Pdev Name Config Sts (MB)---------------------------------------------------------060B N/A TDEV RW 983040}


Ran a baseline benchmark workload with 50 users on the DB2 databases on thetwo Virtual machines with Host I/O Limits of 5000 IOPS on each of them and acascaded Host I/O Limits of 10000 IOPS on the parent storage group. Changed the Host I/O Limits on the above two virtual machines to 4000 IOPS and3000 IOPS respectively. Added a third virtual machine with storage group having

Host I/O Limits of 3000 IOPS to the parent storage group having Host I/O Limits of10000 IOPS.


33/43


Test Results:

Cascaded - Parent Host I/O Limits at 10000 IOPS and 3 children with HostI/O Limits of 4000, 3000,and 3000 IOPS

DB2Database

VirtualMachine

Host I/O Limits setting(in IOPS) IOPS

AverageI/O

responsetime(ms)

App A Lfqu1231

(Child1)4000 3700 8

App B Lfqu2048(Child2) 3000 2970 12.5

App C Lfqu2049(Child3) 3000 2900 11.5

Response time increases for the 2 Virtual Machines when the third VirtualMachine is introduced.

The total IOPS is contained at 10000 IOPS.

The total IOPs of the environment is maintained at 10000 iops so that if thisenvironment were to share front end VMAX ports with a Production application, theperformance of the Production application will not be affected.

Cascaded - Parent Host I/O Limits at 10000 IOPs and 2 children with HostI/O Limits of 5000 iops each

DB2 Database VirtualMachineHost I/O Limitssetting (in iops) IOPS

Average I/OResponseTime(ms)

App A Lfqu1231( Child1) 5000 4900 2.75

App B Lfqu2048( Child 2) 5000 4850 2.5


34/43


Test case 3 : Use Dynamic Host I/O Limits feature to redistribute andfailover Host I/O Limits to online FA directors

This section shows the effect of dynamic distribution to distribute Host I/O Limitsamong online VMAX front end FA directors. Using this feature, Host I/O Limits areredistributed to online directors from directors that are offline or that have failed .

Figure 15 shows the dynamic distribution of Host I/O Limits on FC protocol.


Figure 15 Setup showing Dynamic Distribution of Host I/O Limits on Fibrechannel protocol

The test cases focus was to understand the feature of dynamic distribution of HostI/O Limits and to set the allocation of front end performance Host I/O Limits suchthat the Host I/O Limits are redistributed across all participating directors.


Host AIX232 Model IBM 8202-E4C

Processor PowerPC_POWER7

Memory 23424 MB Storage Array Symmetrix VMAX40K

Disk FC 15K rpm 450 GB

drives Protocol Fibre Channel


35/43


Software Stack:

Host AIX232 Databases AIX_232 ( App A)

O/S AIX 7.1 File system JFS2

DB2 UDB version 9.7.3 VMAX Enginuity 5876.229.145

Multipathing Powerpath 5.5 P 02 Storage Group lfqu1232_db2_stor

The test configuration consisted of a 23 GB IBM DB2 for LUW database running abenchmark workload with 50 users on an AIX P7 system. The Port group consisted of4 VMAX ports all of which were associated with the storage group of the database onwhich the Host I/O Limits had been set. The dynamic redistribution was measured by

bringing down the ports one at a time, and the response time was measured usingSymmetrix Performance analyzer .

Set Dynamic distribution

#symsg -sid 351 -sg lfqu1232_db2_stor set -iops_max 14000#symsg -sid 351 -sg lfqu1232_db2_stor set -dynamic OnFailure

# symsg -sid 351 show lfqu1232_db2_stor


Symmetrix ID : 000195700351Last updated at : Tue Apr 02 10:19:23 2013Masking Views : YesFAST Policy : NoHost I/O Limit : DefinedHost I/O Limit MB/Sec : NoLimitHost I/O Limit IO/Sec : 14000Dynamic Distribution : OnFailure

Number of Storage Groups : 0Storage Group Names : N/A

Devices (8):{---------------------------------------------------------Sym Device CapDev Pdev Name Config Sts (MB)---------------------------------------------------------


36/43


0482 N/A TDEV RW 2447360483 N/A TDEV RW 2447360484 N/A TDEV RW 2447360485 N/A TDEV RW 2447360486 N/A TDEV RW 2447360487 N/A TDEV RW 244736

0488 N/A TDEV RW 2447360489 N/A TDEV RW 244736}


Started workload on the database with Host I/O Limits dynamic distribution seton the storage group. Dynamic distribution on a storage group cannot be setwithout setting Host I/O Limits first. Brought down the FA ports, one at a time, and observed the IOPS gettingredistributed over the ports which are online.

Test Results:

Without Dynamic distribution of Host I O limits

Number of Frontend director ports

online

Time atwhich

taken

IOPS

AverageI/O

responsetime(ms)

All 4 ports up 5.34 PM 14154 43 Ports up 5.36 PM 10484 5.52 Ports up 5.39 PM 7141 6

With Dynamic distribution of Host I O LimitsNumber of Front

end director

ports online

Time atwhich

taken

IOPSAverage I/O

response

time(ms)All 4 ports up 8.30 PM 14293 4.5

3 Ports up 8.32 PM 13991 5.852 Ports up 8.37 PM 14009 6.1


37/43


The Host I/O Limits get redistributed seamlessly to the online FAs wheneverany of the FAs in the Port group go down.

Response time goes up after the redistribution because the existing FAshave to handle more workload now.

14154

10484

7141

0

5000

10000

15000

5.34 PM 5.36 PM 5.39 PM

All 4 ports up 3 Ports up 2 Ports up

IOP

S

Time

Without Dynamic distribution of Host I/O Limits

IOPS

14293 13991 14009

02000400060008000

10000120001400016000

8.30 PM 8.32 PM 8.37 PM

All 4 ports up 3 Ports up 2 Ports up

IOPS

Time

With Dynamic distribution of Host I/O Limits

IOPS


38/43


Test case 4: Use Dynamic Host I/O Limits feature to redistribute andfailover Host I/O Limits to online FCoE directors

This section shows the effect of dynamic redistribution when one or more frontend fibre channel over Ethernet ports in a VMAX port group goes offline. The mainpurpose of this test is to show the support of Host I/O Limits on fibre channelover Ethernet protocol and Dynamic distribution and dynamic failover acrossFCoEs.


Figure 16 shows the dynamic distribution of Host I/O Limits on FCoE protocol.

Figure 16 Setup showing Dynamic Distribution of Host I/O Limits onFibre channel over Ethernet protocol

The focus of the test case is to set the allocation of front end Host I/O Limits suchthat the Host I/O Limits are distributed across all participating fibre channel overEthernet directors. Using this feature, Host I/O Limits are redistributed to onlinedirectors from directors that are offline or that have failed.


39/43



Host AIX122Model IBM 9113-550

Processor PowerPC_POWER5Memory 6720 MB

Storage Array Symmetrix VMAX40K

DiskFC 15K rpm 450 GB

drives

ProtocolFibre Channel over

Ethernet

Software Stack:

The test configuration consisted of a 23 GB IBM DB2 for LUW database running abenchmark workload with 50 users on an AIX P5 system. The Port groupconsisted of 2 VMAX FCoE ports both of which were associated with the storagegroup of the database on which the Host I/O Limits had been set. The dynamicredistribution was measured by bringing down the ports one at a time, andmeasuring the response time.

The following procedure was followed: Started workload on the database with Host I/O Limits dynamic

distribution set on the storage group. Dynamic distribution on a storagegroup cannot be set without setting Host I/O Limits first.

Host AIX122Databases AIX_122

O/S AIX 6.1File system JFS2

DB2 UDB version 9.7.3VMAX Enginuity 5876.229.145

Multipathing Powerpath 5.5 P 02


40/43


AIX_122 is a DB2 UDB database on AIX P5 which sees 2 FCoE ports, 11g:0and 11h:0. Ran a benchmark workload with 50 users. Set iops_max at6000 IOPS. Set dynamic to "OnFailure".

Brought down one FCoE port and observed the IOPS get redistributed overto the port which is online.

Test Results:

Without Dynamic distribution of Host I O limitsNumber of FCoE

director portsonline

Time atwhich taken IOPS

Average I/Oresponsetime(ms)

2 Ports up 11.45 AM 6023 3.51 Port up 11.48 AM 3003 6.5

With Dynamic distribution of Host I O LimitsNumber of Front

end directorports online

Time atwhich taken IOPS

Average I/Oresponsetime(ms)

2 Ports up 12.15 PM 6010 3.81 Port up 12.19 PM 5935 6.5


41/43


The Host I/O Limits seamlessly get redistributed to the online FCoE directorswhenever any of the FCoE directors in the Port group go down.

Response time goes up after the redistribution because the existing FCoEdirectors have to handle more workload now.

6023

3003

0

2000

4000

6000

8000

11.45 AM 11.48 AM

2 Ports up 1 Port up

IOPS

Time

Without Dynamic distribution of Host I/O limits

Series1

6010 5935

0

20004000

6000

8000

12.15 PM 12.19 PM

2 Ports up 1 Port up

IOPS

Time

With Dynamic distribution of Host I/O Limits

IOPS


42/43


Conclusion

Host I/O Limits enable setting workload and bandwidth Limits on applicationssharing resources on a VMAX. They also provide a mechanism for enforcingperformance boundaries and service levels.

The growth of storage needs, year after year, has made us realize the importance ofefficient use of storage and more granular control of storage resources. Host I/OLimits allows us to make more economical and intelligent use of the resources of aSymmetrix VMAX, since multiple tenants or applications can share the availableresources in an effective, easy and transparent manner. It also results in improvedperformance for the more critical applications, reduced overall application costsand an improved use of hardware resources. Management becomes easier as onlythe shared set of resources need to be maintained instead of multiple sets ofresources. The overall energy costs are reduced because this solution allows forsharing of resources, as opposed to dedicating additional resources to individualapplications.


43/43

References

1. Application workload control using Host I/O Limits for SQL Server onEMC Symmetrix VMAX.

2. Storage Provisioning with EMC Symmetrix Autoprovisioning Groups

Technical note

Documents

Docu48440 White Paper Optimizing Application Performance Using VMAX Host I O Limits for DB2 for Linux, Unix, And Windows