SAP Applications on IBM XIV System Storage Applications on IBM XIV System Storage ... SAP customers invest heavily in managing data distribution to maintain performance. ... 1 7 0

2010 IBM Corporation

SAP Applications on SAP Applications on IBM XIV System StorageIBM XIV System Storage

Hugh WasonHugh WasonIBM Storage Product ManagerIBM Storage Product Manager


SAP Storage Market SAP Storage Market -- Why is it Important? Why is it Important?

Storage Market for SAP is estimated at $2Bn+

SAP BW storage sizes double every 1-2 years

Storage value is similar or greater than Server opportunity in new SAP installations

SAP Data is generally core data

SAP customers invest heavily in managing data distribution to maintain performance

2010 IBM Corporation33 Competitive Win-Back with IBM XIV in SAP installed customers

SAP Customer reasons to act:

Complexity of SAP landscape increases constantly

Number of SAP Instances

Number of SAP Applications

Number of Server

Growth of Capacity requirements

Number of Volumes/LUNs to

manage

Volumes of Backups

.

2010 IBM Corporation4

An effective SAP storage infrastructure requires

four main sets of components:

1. Storage Platforms

2. Software Tools for: Point-in-Time Copy

Backup and Recovery

Archiving and Content Management

Business Continuity Management

Storage Infrastructure Management & Other Functions

3. Cross Platform Virtualization Capabilities

4. Storage Area Network (SAN) Integration


The Traditional SAN-Storage Challenge

Parallel GRID Storage Architecture

Reliability for Enterprise Applications

Performance Sizing Guidelines for SAP

Sizing Considerations for virtualized XIV

Backup Strategies for SAP

CAPEX and OPEX Savings with XIV

References / Reference Material

Agenda


Traditional Storage Systems:

Complex & Static Data Layout

You never get optimal performance Unless you stripe everything over everythingwhich is a manual and time consuming task

Data layout planning Optimal performance requirescomplex data layout planing

Several steps required to stripe data Format arrays Create LUNs and map to hosts Group LUNs into a volume group Create striped filesystems across disks

Data layout is static Changes is configurations such as new disks require manual workto redistribute data.

SAP1

SAP2

SAP3


Traditional Storage Systems:

Orphaned Space

Effective Capacity Static dedication of LUNs to disk-arrays leads to orphaned spaces.

De-provisioning of unutilized space is complex and requires manual steps

orphaned spaces

SAP1

SAP2

SAP3


Storage Management - Performance

Traditional Architectures

COMPLEXITY GROWS WITH CAPACITY

REQUIRES MORE Pre-Planning

INCREASED RISK to existing production

REQUIRES MORE monitoring & tuning

LOWER capacity utilization

XIV

COMPLETELY Automated Process

NO Pre-Planning

AUTOMATIC load balancing

HIGHEST capacity utilization


Agenda










From Dual Controller to Parallel GRID Storage

How is XIV different?

Controller-centric

Proprietary/Custom Hardware & Software

Centralized, shared cache

Needs lots of shared bandwidth

Complex cache lock management

How do you scale beyond the controller?

Distributed grid of commodity servers

Proprietary/Custom Software only

Distributed cache

No shared bandwidth needed

No complex lock management

Scales in every dimension

Traditional Architectures

Ca

ch

eC

on

trolle

rs

Interface Interface Interface

JBOD JBOD

XIV Virtualized Storage Software

Module Module Module Module

Module Module Module Module

Switching


Ca

ch

eC

on

trolle

rs

Interface Interface Interface

JBOD JBOD

Traditional Dual Controller I/O

IOs must pass single or dual controller

No parallel IO -> needs fast Disks!

Hot spots most likely to occur due to manual data layout procedureRaid configuration/formattingStripingetc.


IBM XIV Storage System has a unique data distribution technique

Each volume is spread across all drives

Data is cut into 1MB partitions and stored on the disks

XIV algorithm automatically distributes partitions across all disks in the system pseudo-randomly

Data Module

Interface

Data Module

Interface

Data Module

Interface

Switching

XIV Grid Architecture

enabling Virtualization


Data Module Data Module Data Module Data Module Data Module Data Module

Switching Switching

XIVs Massively Parallel Architecture

Data Module Data Module Data Module Data Module Data Module Data Module

Data

All IO parallel !

Totally balanced:Paths, CPUs, Caches, Disks

No Hotspots !


XIV Data Distribution Benefits

All spindles are always utilized

Application get the full system power regardless of access patterns

No management effort or optimization

No Hot-Spot

Rebuild of one failed HDD takes +/-30 minutes for 1TB

Uniform data distribution through entire usage life


Agenda










Data distribution only changes when the system changesEquilibrium is kept when new hardware is added

Equilibrium is kept when old hardware is removed

Equilibrium is kept after a hardware failure

Node 2

Node 3

Node 1

Data Module 2Data Module 1

Data Module 3

XIV Storage Distribution Technique

System Change #1


Node 4

Data Module 2

Data Module 3

Data Module 1

[ hardware upgrade ]

Data Module 4

Data distribution only changes when the system changes

Equilibrium is kept when new hardware is added




System Change #2


Data distribution only changes when the system changes

Equilibrium is kept when new hardware is added



Data Module 2

Data Module 3 Data Module 4

Data Module 1

[ hardware failure ]


System Change #3


Lets look at some real live test (customer)


Reliability Live Tests

Test series I: Singe + Double Disk Failures (36 TB Data)

1.Test: Single Disk Failure17:14 Removed one Disk. XIV starts redistribution17:16 - Redistribution finished. System full redundant.

2.Test: Double Disk Failures17:25:53 and 17:25:57 : Disk 14:7 and 14:6 removed17:27:17 Data Redistribution completed

Test series II: Total Module Failure (52 TB Data)

3. Test: Total Module Failure14:20:12 Remove Power from Data Module -> immediate down14:45:45 Data Rebuild finished


Test series I: Rebuild Statistics

Overall 17 Disks failed within one hour and XIV is still full redundant after some minutes


Autonomic Rebuild : Event Log


Heavy availability test

Tested failure of 3 Modules within 2 hours No problem since redundancy recovered much faster

At the same time Module failure

Switch failure

UPS failure

XIV lost not even a single bit !


Agenda










Storage Sizing Guidelines for SAP

Storage system are sized based on number of SAPS it can service: ERP (OLTP) 1 SAPS is equivalent to approx. 0.4 IO per sec BW/BI (OLAP) 1 SAPS is equivalent to approx. 0.6 IO per sec

The service time performance constraints of a SAP ERP application: between 5 and 7 ms targeted / excepted between 10 and 15 ms - considered good above 20 ms - considered as performance bottleneck beyond 30 ms - system does not behave as expected towards the users

Interactive type workload: OLTP with random access patterns. Standard estimation for sizing: 70/30/50

Batch type workload: Sequential workload

8-64 kB Blocksize for BW loads etc. 256 kB Blocksize for Backup/Restore


SAP OLTP Workload with XIV

Typical Random OLTP Workload with 70/30/50 and 8kB Blocksize

Guideline: XIV can handle up to 50,000 IOPS with < 15ms

0

2

4

6

8

10

12

14

16

1000

3000

5000

7000

9000

1100

013

000

1500

017

000

1900

021

000

2300

025

000

2700

029

000

3100

033

000

3500

037

000

3900

041

000

4300

045

000

4700

049

000

5100

053

000

Total I/O Rate (I/Os per second)

Se

rvic

e T

ime

in

ms

(O

pe

n)

OLTP 70/30/50

OLTP 50/50/50

OLTP 30/70/50


OLAP Workload

90% read and write model (see graph)

Of which 90% are sequential

64 kB Blocksize

OLAP 64k seq.

0

2

4

6

8

10

12

14

16

18

160

224

288

352

416

480

544

608

672

736

800

864

928

992

1056

1120

1184

1248

1312

1376

1440

1504

1568

1632

1696

1760

1824

1888

1952

2016

2080

MB/s

ms

OLAP 90% read

OLAP 90% write


Performance Guidelines Across all Configurations

Note: From IBM XIV Storage Systems Specifications March 2010


Scalable Sequential Bandwidth

Results based on a large number of concurrent 1MB sequential streams

Measurements done with XIV Release 2.2 hardware and Release 10.2.1 software

0

500

1000

1500

2000

2500

3000

3500

Th

rou

gh

pu

t (M

B/s

ec

)

Read Write

Sequential Bandwidth

6 Mod 1 TB 15 Mod 1 TB


100% Cache Miss Scalable Random I/O

Results are for data to/from disk with 4 KB transfer size.

XIV disk technology typically achieves up to 100 read IOPS per disk spindle. Writes may substantially exceed 100 IOPS per disk due to seek optimization

Because of write cache efficiency and seek optimization, random write IOPS are slightly better than random read despite mirroring!

0

2

4

6

8

10

12

14

16

18

Th

rou

gh

pu

t (K

IO/s

ec)

Random Read Random Write

Random I/O

6 Mod 15 Mod


4 KB Cache Hits Scalable Random I/O

Results are for data to/from cache with 4 KB transfer sizes

Note: The 6 Mod read hit value is estimated based on measurements with a single Interface Module and three Interface Modules. A two Interface Module test was delayed due to server availability issues but is planned near term.

0

20

40

60

80

100

120

140

160

180

Th

rou

gh

pu

t (K

IO/s

ec

)Read Hit Write Hit

Cache Hits

6 Mod 15 Mod


Sequential Bandwidth Performance Comparison

Results based on a large number of concurrent 1MB sequential streams

Overall sequential performance of XIV with 2 TB disk drives is equivalent to XIV with 1 TB disk drives


0

500

1000

1500

2000

2500

3000

3500

Th

rou

gh

pu

t (M

B/s

ec)

Read Write

Sequential Bandwidth




Random IOPS Performance Comparison Full Rack

Results based on a large number of concurrent random streams

Random reads/writes are 100% cache misses.

Overall random performance of XIV with 2 TB disk drives is more or less equivalent to XIV with 1 TB disk drives


0

5000

10000

15000

20000

25000

30000

Th

rou

gh

pu

t (I

O/s

ec

)4KB

Random

Read

4KB

Random

Write

64KB

Random

Read

64KB

Random

Write

Random IOPS

1 TB XIV 2 TB XIV


Agenda










SAP Random I/O Characterization

Traditionally application determines whether writes and reads are sequential or random

As more Servers are attached to a storage system, the read & write data

patterns to disk become more randomized

High random read & write access greatly reduces traditional disk performance

Disk bottlenecks reduce the consolidation ratio in the virtual infrastructure


The XIV Storage System already optimizes for random read/write access

XIV read blocks in parallel and are not relying on sequential blocks for high IO

Random seek times dramatically reduced

More granular and efficient caching

Highest performance for consolidated environments

SAP Random I/O Characterization


Sizing Consideration for XIV

Customer Example

Customer has 40 Clients (SAP instances), each requiring 5,000 SAPS 40 x 5,000 SAPS = 200,000 SAPS ~ 100,000 IOPS

With Traditional Storage (dedicated LUNS to arrays) we have to have a storage system providing 100,000 IOPS

With manual planning and implementing Static layout etc

XIV being totally virtualized, All LUNs use All physical disk& As customer (instances) have Peaks at varying times, XIV handles such IOPS Load without planning required with conventional arrays

And think about your Test + Development environment XIV provides unlimited snapshots without performance penalty Saved huge amount of disks space (compared to data copies)

SAP 1

SAP 2

SAP 3

SAP 4

SAP 5

SAP 6

SAP N


Agenda










XIV Storage SNAPs with No Limitations

SNAPs creation/deletion is instantaneous

High Performance WITH SNAPs

Unlimited number of SNAPs (16,000)

SNAP creation/deletion is instantaneous

Differential SNAPs save 15-30% of storage capacity

SNAP on SNAP (with clones)

Excellent VSS SupportVolume

Vol

Snap

Snap

Distributed SNAP on each Server. Extremely fast memory operations

Accessing SNAPs is as fast as accessing production volumes

As Host Writes data, it is placed

randomly across system in 1MB chunks

Each Server has pointers in memory to

the disks that hold the data locallyOn a SNAP, each Server simply points

to original chunks. Memory only

Operation

Restore Volume from SNAP copy

High Performance SNAPs provide:

Easier Physical Backup to Tape

Instant recovery from Logical Backup

Easy creation of Test and Dev. Environment

Boot-from-SAN with easy rollback

Easy Data-Mining on Production data


Snapshot creation/deletion is instantaneous

Takes 150 msfor any size of system, any capacity

High performance WITH snapshots

Unlimited number of snapshots

Differential snapshots save 15-30% of storage capacity

Snapshots on snapshots (with clones)

IBM XIV Snapshots


XIV Storage: Functionality #3a

Low Granularity Any-to-Any volume replicationo Every I/O is committed to local & remote copies before completion

Link Failure Policies:

o Various policies upon link failure

o Re-sync when link is resumed

o Full completion or Fail

o Automatic Snap used to keep copies self-consistent even during re-sync after

link failure

Preserves write order

o Copies are self-consistent even during re-sync after link failure

Flexible restore options:

o Local servers and remote data

o Remote servers and remote data

o Remote server and local data

Remote Mirroring / Replication : Sync / Async

Over dedicated FC or IP ports


Users define volumes with any logical size

Users acquire only the physical capacity of XIV Storage needed for data that is actually written

The part of the volume that contains no data does not consume any physical space

Thin Provisioning

Actual Data

Written 10GB

Actual Data

Written 30GB

Actual Data

Written 20GB

Volume 30GB

Volume 50GB

Volume 70GB

Fat provisioned Thin provisioned

Amount of physical storage required

Actual Data

Written 10GB

Actual Data

Written 30GB

Actual Data

Written 20GB

Volume 30GB

Volume 50GB

Volume 70GB

150 GB

60 GB


Soft volume capacity The size viewed by hosts the traditional volume size Configurable by users

Hard volume size The physical disk capacity available to applications Depends on how much data the applications write to disk Not configurable by users Will be less than or equal to the soft volume size Increasing volume size does not effect hard volume size

Soft system size The logical limit of the sum of the sizes of the volume(s) defined in the system Not related to any direct system attribute Can only be set larger than hard system size if thin provisioning is used

Hard system size The total physical capacity that was purchased or installed Upper limit on the total hard capacity of all volumes Can only change by installing new hardware

Thin Provisioning


XIV Functionality #4a

Data Migration Features: Automatic array based data migration

Online data migration from other Storage arrays

No host resources consumed

Writes to Source storage passed through XIV

Migrate thick volumes to thin provisioned volumes

Migration Speed - tuneable: 300GB/Hr to 1TB/hour

New hardware - can be added to the system

Outdated Hardware - Phased Out & Removed

Non Disruptive Change - No downtime - No host re-configuration

Data Migration


Agenda










Tradition

al RAID

System

IBM XIV System

Year 4

30%less

60% less

Cost

Year 1 Year 2 Year 3

From the beginning:

No orphaned space

Thin Provisioning

Thick-to-Thin Migration

During runtime:

Space efficient Snapshot

Dynamic re-distribution

No orphaned space

Thin Provisioning

Lower CAPEX with XIV


TCO Savings with XIV

0

20

40

60

80

100

120

TCO-$ XIV-TCO-$

Facilities

SW

HW

Admin

Hardware cost

20%

Software cost

30%

Facilities

25%

Administration

50%

XIV administration is smarter !!

Case Study International Technology Group, July 2009


XIV Functionality Overview

Not avail. or $$$IncludedThin Provisioning without performance penalty

Not availableIncludedParallel Storage GRID

xxxx.xx $$$IncludedData Migration

xxxx.xx $$$IncludedRemote Mirror

xxxx.xx $$$IncludedSuperior Snapshot

Not availableIncludedDynamic Load Distribution

Not availableIncludedFully Virtualized Storage Subsystem

CompetitionXIV


Summary: Key Properties of a Groundbreaking Solution

Very easy administration

Automatic performance optimization without administrative overhead

Market leading auto-restoration of system redundancy

No volume layout required

SNAP Backup/Restore to reduce backup windows & fasten restore process

Thin Provisioning to increase disk utilization


Acquisition costs S/W included: Mirroring, Snapshot, Thin Provisioning, Data

Migration

Commodity Hardware reduces the price

SAN and iSCSI support included

up to 30%

Management costs Almost no training necessary

Almost no maintenance needed, e.g. Self Healing

No performance bottlenecks, due to automatic Load Balancing

up to 80%

Capacity utilization Physical capacity utilization above 95% possible

Thin Provisioning for optimal Provisioning, no waste of space

Space efficient Flash Copy, more than 10,000

up to 50%

SAP databases grow at phenomenal rates


How XIV supports SAP Customers

Reduce TCO

No Hidden costs, SW included

Low costs for training and administration

High capacity utilization

Easy to Manage

SAP Data Base growth is managed automatically, by adding

additional modules No hotspots, automatic on-going

workload distribution

Performance out of the box

Integrated Performance Monitoring and Analyses

Optimal integrated Data Management

Integrated Data Base backup solution through Tivoli Storage

Manager

Space efficient flash copy and thin provisioning reduces space

requirements for SAP backup and cloning up to 80%

Integrated Data Migration

XIV Value Proposition


Agenda










CRMDCRMD 79 Published and Growing79 Published and Growing

Indicates Case Study Indicates Case Study

on file as well.on file as well.

Indicates Customer Indicates Customer

Video Testimonial.Video Testimonial.


Markus Fehling

Senior Specialist Storage Solutions

Technical Sales enablement for SAP @ ISICC

DB Sizing and Layout for SAP


Disclaimer

Copyright 2010 by International Business Machines Corporation.

This publication is provided AS IS. IBM product information is subject to change without notice.

No part of this document may be reproduced or transmitted in any form without written permission from IBM Corporation.

Product data has been reviewed for accuracy as of the date of initial publication. Product data is subject to change without notice. This information could include technical inaccuracies or typographical errors. IBM may make improvements and/or changes in the product(s) and/or programs(s) at any time without notice. The information provided in this document is distributed AS IS without any warranty, either express or implied. IBM EXPRESSLY DISCLAIMS any warranties of merchantability, fitness for a particular purpose OR INFRINGEMENT. IBM shall have no responsibility to update this information. IBM products are warranted according to the terms and conditions of the agreements (e.g., IBM Customer Agreement, Statement of Limited Warranty, International Program License Agreement, etc.) under which they are provided.

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products.

IBM makes no representations or warranties, expressed or implied, regarding non-IBM products and services, including those designated as ServerProven.

IBM may not offer the products, services or features discussed in this document in other countries, and the information may be subject to change without notice. Consult your local IBM business contact for information on the product or services available in your area.

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.

Documents

SAP Applications on IBM XIV System Storage Applications on IBM XIV System Storage ... SAP customers invest heavily in managing data distribution to maintain performance. ... 1 7 0