SAP Applications on IBM XIV System Storage Applications on IBM XIV System Storage ... SAP customers...
Transcript of SAP Applications on IBM XIV System Storage Applications on IBM XIV System Storage ... SAP customers...
-
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
-
2010 IBM Corporation
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
-
2010 IBM Corporation5
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
-
2010 IBM Corporation6
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
-
2010 IBM Corporation7
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
-
2010 IBM Corporation8
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
-
2010 IBM Corporation9
Agenda
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
-
2010 IBM Corporation10
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
-
2010 IBM Corporation1111
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.
-
2010 IBM Corporation12
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
-
2010 IBM Corporation1313
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 !
-
2010 IBM Corporation14
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
-
2010 IBM Corporation15
Agenda
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
-
2010 IBM Corporation16
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
-
2010 IBM Corporation17
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
Equilibrium is kept when old hardware is removed
Equilibrium is kept after a hardware failure
XIV Storage Distribution Technique
System Change #2
-
2010 IBM Corporation18
Data distribution only changes when the system changes
Equilibrium is kept when new hardware is added
Equilibrium is kept when old hardware is removed
Equilibrium is kept after a hardware failure
Data Module 2
Data Module 3 Data Module 4
Data Module 1
[ hardware failure ]
XIV Storage Distribution Technique
System Change #3
-
2010 IBM Corporation19
Lets look at some real live test (customer)
-
2010 IBM Corporation20
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
-
2010 IBM Corporation21
Test series I: Rebuild Statistics
Overall 17 Disks failed within one hour and XIV is still full redundant after some minutes
-
2010 IBM Corporation22
Autonomic Rebuild : Event Log
-
2010 IBM Corporation23
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 !
-
2010 IBM Corporation24
Agenda
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
-
2010 IBM Corporation25
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
-
2010 IBM Corporation26
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
-
2010 IBM Corporation27
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
-
2010 IBM Corporation2828
Performance Guidelines Across all Configurations
Note: From IBM XIV Storage Systems Specifications March 2010
-
2010 IBM Corporation2929
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
-
2010 IBM Corporation3030
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
-
2010 IBM Corporation3131
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
-
2010 IBM Corporation3232
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
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 6 Mod 2 TB
15 Mod 1 TB 15 Mod 2 TB
-
2010 IBM Corporation3333
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
Measurements done with XIV Release 2.2 hardware and Release 10.2.1 software
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
-
2010 IBM Corporation34
Agenda
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
-
2010 IBM Corporation35
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
-
2010 IBM Corporation36
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
-
2010 IBM Corporation37
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
-
2010 IBM Corporation38
Agenda
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
-
2010 IBM Corporation39
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
-
2010 IBM Corporation40
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
-
2010 IBM Corporation41
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
-
2010 IBM Corporation42
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
-
2010 IBM Corporation43
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
-
2010 IBM Corporation44
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
-
2010 IBM Corporation45
Agenda
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
-
2010 IBM Corporation
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
-
2010 IBM Corporation47
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
-
2010 IBM Corporation48
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
-
2010 IBM Corporation49
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
-
2010 IBM Corporation5050 Competitive Win-Back with IBM XIV in SAP installed customers
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
-
2010 IBM Corporation5151 Competitive Win-Back with IBM XIV in SAP installed customers
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
-
2010 IBM Corporation52
Agenda
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
-
2010 IBM Corporation53
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.
-
2010 IBM Corporation
Markus Fehling
Senior Specialist Storage Solutions
Technical Sales enablement for SAP @ ISICC
DB Sizing and Layout for SAP
-
2010 IBM Corporation55
-
2010 IBM Corporation56
-
2010 IBM Corporation57
-
2010 IBM Corporation58
-
2010 IBM Corporation59
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.