IBM XIV Gen3 Overview

XIV Essentials:
Everything you wanted to know about XIV!
Jinesh.shah@in.ibm.com
2012 IBM Corporation

Agenda
XIV hardware and architecture

Snapshots
Thin Provisioning
Replication
Data migration
Performance
VMware integration
Monitoring
XIV Gen3 and SSD Update
Additional Resources
2 IBM System StorageTM 2012 IBM Corporation
XIV A Brief History
XIV was founded in 2002 and acquired by IBM in- December 31st, 2007
Disruptive, next generation grid technology providing one general purpose, fully
virtualized storage platform
Full global IBM integration, development, support and services
What this means for our customers:

Revolutionary next-generation storage product
Established IBM support and services

XIV Sustained Market Growth
State of the Business

Over 5,800 units shipped
New business to IBM: >1,300 new clients (118 in 4Q)
Loyal customer base
Rapid Gen3 adoption 80% of capacity sold in 4Q 2011
Clients with 1 PB+ (usable): 59
Clients with 2 PB+ (usable): 16

Driving value across the IBM portfolio
Winning design: Announced CeBIT 2012 iF Design Innovation Award
Driving Tivoli Flash Copy Manager, ProtecTIER, SVC and SoNAS solutions in IBM white
space
Broad adoption of XIV GUI (SVC, v7000, DS8000, SONAS,)

XIV Global Footprint
Usable Petabytes
350
300 348
289
250
256
200
226
209
150
160
100 128
95
50 77
46
1 1 3 12 18 31
0

Sampling of XIV Installations
IBM XIV Storage System is

allowing us to meet our recovery
time objectives while reducing our
storage total cost of ownership
Greg Johnson, Director & CTO, IT
Technology & Engineering Services,
VCU Health Systems
We are exceeding our SLAs and

driving cost down". Maher Atwah,
Ph.D. Vice President and CTO
Health Data Management
Solutions (HDMS) a Aetna
Subsidiary

Ongoing Evolution of the XIV Storage System
Aug 2008
XIV Gen2 Feb 2011 Oct 2011
2810-A14 XIV Gen2 XIV Gen3
V10 S/W V10.2.4 S/W R11.0.1
2006 15 Module Oct 2009 VMware VAAI 3TB Drives
XIV Gen1 1TB DDM Mar 2009 XIV Gen2 QoS 243TB Capacity
(Nextra) 4Gb FC XIV Gen2 R10.2 S/W Offline Init VMware VASA
V9 S/W 6 15 Module Async Mirroring
1.0 1.1 2.0 2.1 2.2 2.3 2.3 2.4 2.4 6.2
3.0 3.01 3.1
Jan 2008 Dec 2008 Jul 2009 Apr 2010 July 2011 March 2012
IBM XIV Gen2 XIV Gen2 XIV Gen2 XIV Gen3 SSDs for Gen3
Acquisition 6 Module V10.1 S/W V10.2.1 S/W InfiniBand R11.1
Faster CPU 2TB Drives New Modules Gen2 Gen3
Concurrent Code Load 240GB Cache 360GB Cache mirroring
Capacity on Demand 161TB 8Gb FC GUI enhancements
2812-A14 for warranty capacity SRM5
LDAP
GUI Enhancements
Thin Provisioning, Snapshot, Remote Mirroring included at No Charge
Ease of use Management Graphical User Interface (GUI)

IBM XIV Hardware and Architecture

Escalating Complexity of Traditional Storage
Disk Configurations to Manage

1-6 Types and Sizes of Disk
Flash/SSD? This results in
Replica Pool THOUSANDS of
components to
Spares manage in a
traditional array!
Many RAID groups / Different RAID Levels
Complexity = COST =
Data Center Efficiency Diminished
Power Service
Space
Utilization
Responsiveness / Cost to Business Units
With XIV, manage storage capacity - NOT technology!

XIV Altering the Landscape of Enterprise Storage
The simple vision of XIV:
Begin with a blank sheet of paper
Blend in decades of expertise and innovation in storage
architecture and customer/market demand
Create a fundamental re-construction of enterprise storage
not constrained by existing architectures and technologies
The solution
Revolutionary best-in-class performance, reliability, scalability, manageability and TCO
The results:
Grid based block storage
In service at the largest, most demanding customer sites in the world
Steady increase in captured market share during first year within IBM portfolio
Strong, balanced cross-industry adoption
Outstanding customer satisfaction and reference-ability
Use cases spanning a wide variety of mission-critical applications and workload profiles
XIV has disrupted the storage market by doing one thing extraordinarily well: eliminating
complexity rather than merely masking it

What is XIV storage? AVAILABILITY
Fully virtualized SAN based on grid 5 9s+

design Multiple levels of redundancy
Data distributed over all grid Autonomous self-healing
modules/drives
Ultra-fast fault recovery
Self-healing/self-tuning no hotspots
Non-disruptive hardware and software
service
Supports all major open systems, Linux PERFORMANCE
Drive out cost
on System z, IBM I (via VIOS) Self-tuning while
Sold as usable capacity Automatic load balancing eliminates exceeding
Each grid node comprised of CPU + bottlenecks existing
Cache + 12 disks SLAs.
Performance scales with capacity
Ultra fast rebuild times:
Recover from a 1 TB drive failure in 30
minutes or less for most workloads
EASE OF USE
Dynamically add new capacity;
autonomic load re-balancing Provision new storage in <1 minute
Dynamically resize/adapt
New arrays in service in 4 hours
Easily managed by junior staff
Provision new storage in < 1 minute

XIV System Components
FC
Host XIV Module
SSD
Data
Host Modules
iSCSI XIV Module

SSD
Interconnect
Host Interface
Modules
Module XIV Module

SSD
CPU(s)
Memory Interface
Modules
12 disk drives
XIV Module
Optional SSD (Gen3) SSD
Data
Interconnect Modules
Full rack
15 Modules
UPS UPS UPS
Partial rack
6, 9-14 modules

XIV Architecture Details
Ground-breaking
Architecture Large Processing Power (Modules)
Grid Architecture
Innovative and Powerful Caching
12x 2TB/3TB SAS Disk,
Autonomic data24GB
layoutCache & grid
across 1Quad Core
CPU
Aggressive, parallel
forpre-fetching
Other solutions FC
Massive parallelism IO processing
Host XIV Module Huge internal bandwidth

Clustered Controllers Variable block-size
InfiniBand cache
interconnect
SSD
Host High cache-to-disk bandwidth
Simpler cache management
RAID protections
iSCSI XIV
XIV Module
Long RAID rebuilds
XIVModule
XIV
XIV Module
Module
Module Module services
Higher only
cache its own disks
hit-ratios
SSD
Host
Require LUN/Disk Layout Consistent performance through workload changes
Internal (peak or average)
Connectivity
XIV
XIV Module
XIVModule
XIV
XIV Module
Module
Module
Performance tuning
SSD
Active/Active IO parallel access Optional 6TB Read Cache Acceleration
Disk Hot-Spots
Zero tuning or manual intervention
Islands of storage

XIV Architecture Details (2)
Ground-breaking
Architecture Scalable and sustained high performance
Unprecedented Resiliency
FC
Other solutions Host XIV Module
SSD
Minimum operations impact upon disk failure (<1%) or
Manual intervention Host module (<7%)
Redesign after changes iSCSI XIV

XIV Module
XIVModule
XIV
XIV Module
Module
Module Automatic rebalancing even after a system component
failure or during rebuild
SSD
Capacity-only scalability Host
Internal
Connectivity
Automatic data rebalancing after new disk/module
XIV
XIV Module
XIVModule
Performance tuning XIV
XIV Module
Module additions
Module
SSD
Continual data movement
XIV utilization always balanced regardless of
add/delete/resize LUNs
XIV
XIV Module
High impact after any failure XIVModule
XIV
XIV Module
Module
Module
SSD
Linear scalability on capacity and performance

XIV Grid Based Scaling
Grid scaling improves performance

Massive parallelization scales linearly with each module
Add disk, cache, I/O bandwidth, and CPU with each module
Automatically rebalanced after any hardware changes
Grid scaling reduces administrative tasks

Consistent performance - no disk hot spots
No-hot spot design ideal for automated environments like cloud
Single tier reduces administrative effort
No islands of orphaned capacity

Not limited by RAID constraints
Thin provisioning
Can increase utilization to over 90%
Quality of Service capabilities

Traditional Approach to Building Storage Systems
Exchange
Oracle Hardware Bound

ILM, Disks, Tiers,
RAID 5
Spares, RAID,
Scalability etc. and
is limited
300 GB 15K
RAID 5 not linear
1 TB
Performance
Hot-Spots
RAID 5 300 GB Capacity isand
added but
Short-stroking
VMware RAID 5 300 GB Performance
performance issues
is reduced
RAID 5
Requires tuning
require analysis, design
146 GB
To
andimprove
tuning performance,
RAID 5 Hot
300 GB Spares
a redesign/relay
Poor out is
System Utilization
RAID 1/0 RAID 5 required
Performance
146 GB 146 GB Capacity
RAID 5 Lots of work to keep and
ERP 146 GB maintain this array

XIV Solution Architecture
Each logical volume is spread across all drives

Data is cut into 1MB partitions or chunks and stored on the disks
XIVs distribution algorithm automatically distributes partitions across all disks
in the system
Even data distribution ensures balanced performance
No hot spots
No tuning
Hardware can be added/removed with no downtime
Performance remains balanced

XIV Scalability
Exchange
New Data
Oracle and Volumes
are laid out
on whole
new-larger
grid
VMware
New and
existing
volumes take
advantage of
the larger
grid
ERP

XIV vs. Traditional Architecture Disk Utilization
The result? We go
Tofrom this
this
Traditional Arrays IOPS profile: Unbalanced Disk Layout
XIV IOPS / Balanced Disk Layout
IOPS
IOPS
Disks
Disks

XIV Data Redistribution (Adding Capacity)
When capacity is added (CPU Cache and Connectivity)
Equilibrium is maintained
Microcode automatically rebalances the Grid
All attached Hosts immediately take advantage of added components
Data Module 1 Data Module 2

IB
Data Module 3 DataNode

Module
4 4
[ hardware upgrade ]
XIV Data Redistribution (Failure Scenario)
Intelligently reacts to HW faults
Equilibrium is always kept
Single Disk Idle Rebuild (idle)
Eliminates parity limitations
100% capacity used Gen2 1TB Gen3 2TB Gen3 3TB
Superior data integrity completion time (min) 30 48 76
Component phased out
Auto Rebalancing during Data Module 2

Data Module 1
hardware failure IB

XIV Feature Summary
Powerful
Features
Enterprise-class, Robust Features All Included

Unique snapshot technology
Simple, dynamic QoS
Powerful synchronous and asynchronous mirroring
Streamlined data migration
Strong host software support
Native thin provisioning with thick-to-thin migration
Comprehensive management of events,
statistics and performance
Advanced LDAP-based authentication
Secure role-based access control

IBM XIV Snapshots

XIV Snapshots: Powerful and Efficient Local Replication
Differential snapshots / almost unlimited
Volume Fast creation (~150ms)
Pointer Map
Same performance
Any combination of snaps
Data Chunks
Snapshot
Snapshot
Pointer Snapshot
Map
Pointer Snapshot
Map
Pointer Map
Pointer Map Data Module 1 Data Module 2
IB

XIV Snapshots - Restore
Restores are instantaneous since they only manipulate

Volume pointer maps. Any snap, regardless of order, can source
Pointer Map a restore.
Data Chunks
Snapshot
Snapshot
Pointer Snapshot
Map
Pointer Snapshot
Map
Pointer Map
Pointer Map Data Module 1 Data Module 2
IB

XIV Consistent Snapshot Groups
Crash or power-loss consistency across multiple volumes
Dependent write consistency
Source volumes are placed in a Consistency Group Storage Pool
Within a single Storage Pool Consistency Group
Consistent Snapshot Group is created from Consistency Group Source Source

Volume Volume
A volume may be in 1 Consistency Group
Easy movement in and out of Consistency Group

Snapshot Snapshot
10am 10am
Maximum of 128 volumes per Consistency Group
Snapshot Group
Maximum of 256 Consistency Groups per system

For simplicity, use the minimum number that meets requirements
For application consistency, XIV integrates with FlashCopy

Manager to create Snapshot Group when application is in a
consistent state

IBM FlashCopy Manager
FlashCopy Manager
Application
System Local
Application Snapshot
Data Versions
Snapshot Online, near instant snapshot
Backup backups with minimal
performance impact
High performance, near

instant restore capability
Integrated with IBM Storage

For IBM and non-IBM Storage Storage Manager 6 Hardware
With Optional Simplified deployment
TSM Backup
SVC
XIV Integration
DS8000
Storwize
V7000
DS 3/4/5*
*VSS Integration
IBM XIV Thin Provisioning

XIV Thin Provisioning can Lower Storage Costs
Soft Space
XIV is data aware (Logical Capacity)
Works on written data only
Volumes, snapshots, replication, rebuilds
Hard Space
(Actual Capacity)
Storage pool logical construct
Used for administrative purposes
Volume 3
Physical partitions are spread across all drives
No performance impact
Volume 2
Storage pool types
Regular: Soft = Hard
Thin: Soft > Hard
Can convert between regular and thin pools
Volume 1
Allows storage to be allocated as needed without

host changes Defined Used space

What Does it Take to Provision XIV Storage?
1. Define a Storage Pool

Thin or Thick Provisioning
VMware 20TB
Size
2. Define Volumes in the Pool

How many
Size
3. Define a Host
Add WWPN/IQN
4. Map volumes to host

XIV Ease of Use Video: http://www-03.ibm.com/systems/data/flash/storage/disk/xiv/user-experience/index.html

Managing Capacity Using XIV Storage Pools
Storage Pools
Usage example -- Multiple storage pools

Capacity isolation 10TB
Capacity protection for loved ones
Capacity limitation for badly behaved
Different applications
Different servers 20TB
Different organizations
Capacity chargeback
Different thin provisioning/regular provisioning
requirements
Snapshot capacity isolation 9TB
Usage example -- Single storage pool
Single application accesses the XIV system
All volumes require a consistent set of Snapshots
Maximum storage pool size 40TB
243TB
161TB/243TB with R11.1

XIV Volume
Storage Pools
Created from space in one pool 10TB

34 17 34 34
Space allocation in 17GB increments
May be presented in 512B blocks
All volume space is spread across ALL disk drives 20TB

All volumes spread across all disk drives in mirrored 1MB chunks
1013 1013
All volumes get full performance potential of entire XIV system 17 17
Thick/thin provisioning depends on pool type 9TB

17
Easy, dynamic changes to both volumes and pools 40TB

Increase/Decrease volume size
51
Move volumes between pools 51 51
51 51
Increase/Decrease pool sizes (hard, soft, Snapshot) 51v 51
51 51
Change pool thick/thin type 17
17

IBM XIV Replication

XIV Remote Replication
Storage-based mirroring
Application-independent
Operating system-independent
No server cycles usage
Volume-based mirroring
Synchronous / Asynchronous mirroring
One-to-one relationship between a source volume and a target volume (a pair)
Up to 8 source target system pairings
Multiple volume pairs may be handled as a single unit (a consistency group)
Only actual data is replicated
Resizing and thin provisioning support
Failover / failback
No extra charge
Uses of XIV Replication
Single location
Protection against hardware failure
High or continuous availability
Clustering
Metro region
Protection against local disaster
Out-of-region
Protection against regional disaster
Additional uses of XIV replication

Planned outages
Remote Backup
Data Center Migration

XIV Replication Granularity
Mirror Volumes or Consistency Groups

Bi-directional mirroring supported
Source Target
Volume Mirror Mirrored volume

Replication changes (activate, deactivate, change
roles) are taken for an individual volume
Usage example single volume with replication
requirements that do not fit a group
Mirrored CG
Mirrored Consistency Group

Multiple volumes (in the same Storage Pool)
Replication changes (activate, deactivate, change
roles) are taken for entire group simultaneously and
in a single action
Usage example group of volumes with dependent
write data

XIV Synchronous Replication -- Normal Operation
Application Server
1
2
4
3
Local XIV Remote XIV
1. Write to local XIV (placed in cache in 2 Modules)

2. Write copied to remote XIV (placed in cache in 2 Modules)
3. Write complete from remote XIV to local XIV
4. Write complete to application
Response time = 1+2+3+4

XIV Asynchronous Replication
Application Server
3
2
1. Write to local XIV (placed in cache in 2 Modules)

3. At an independent time, data replicated to remote
Response time = 1+2 (unaffected by replication)

XIV Asynchronous Replication -- Normal Operation
Application Server
1
2
1. Write to local XIV
6
(Written to cache in 2 modules)
Sync Job
Master Slave
On scheduled interval or by command: 3
4
3. Snapshot of Master (Most Recent) 5
4. Compare Most Recent to Last Most Recent
Last
Snapshot
Replicated and send changes via Replicated
Snapshot
sync job
5. When sync job is complete, overwrite Last
Replicated
Snapshot of Slave (Last Replicated) Snapshot
6. Notification sent from remote XIV

system to local XIV system
7. Most Recent renamed Last Replicated
on local XIV system

Basic XIV Replication Configurations
Target
One local system to one remote system
S Most common configuration
M
S Target Simultaneous bi-directional (different volumes)

Target M Usage example 2 active sites

Basic XIV Replication Configurations (2)
Target
One local system to multiple remote systems (Fan out)
Usage examples:
Smaller systems at remote site
Systems with different amounts of capacity available for DR target usage
Target
Multiple local systems to one remote system (Fan in)

Usage examples:
Target Use with caution - do not overload remote system
Subset of capacity on multiple local systems is replicated to a single
remote system
Capacity on multiple smaller local systems is replicated to single larger
remote system
Single Disaster Recovery center protecting multiple production centers
Target system at service provider

Replication with XIV - FC Ports
Use dedicated FC ports
Port 4 in each module is configured as a Fibre Channel initiator by default
Typically use Ports 2(target) and 4 (initiator) for replication
Any FC port may be configured as initiator or target
Use a minimum of 2 connections (each way) for availability

Use more as necessary for workload
Also define connections in reverse direction for return after disaster recovery
Spread connections across modules
Connect same module on each system (e.g. 9 to 9)
FCIP routers can be used (check SSIC)
WDMs can be used (ensure BB credits are sufficient)
XIV Gen2 <-> Gen3 fully supported
Site 1 Target
9 FC SAN 9
8 8 Site 2
7 7
6 6
5 5
4 FC SAN 4

Replication with XIV - iSCSI Ports
Use dedicated iSCSI ports

Use a minimum of 2 connection pairs for availability
Use more as necessary for workload
Spread connections across modules
Connect same module on each system (e.g. 9 to 9)
Local Understand link quality, latency and actual BW available for replication Target
Site 1 Use deployment experts to optimize solution Site 2
XIV Gen2 <-> Gen3 fully supported
9 IP Network 9
8 8
7 IP Network 7
6 6
5 5
4 4

IBM XIV Data Migration

IBM XIV Data Migration
Moving data from legacy storage systems to XIV systems

Volume-level hardware migration
Offloads migration processing from production servers
Migrate from any vendor storage system
XIV Data Migration Benefits

Minimal downtime
Brief outage to change server access from legacy LUNs to XIV LUNs
Great performance
User-specified rate
Extremely easy to manage
Thick to thin reduces capacity required on XIV

IBM XIV Data Migration - Process
Server
1. Server is connected to legacy system & accessing legacy LUNs

2. Disconnect server from legacy system 5 6
Remove any proprietary device drivers from server
Prepare system to use native multipathing MPIO
3. Connect XIV to legacy system
Define XIV as a Linux host to legacy system
XIV
1
Map legacy LUNs to XIV host
4. Start migration
XIV copies LUN sequentially
5. Connect server to XIV
Map new XIV LUNs to server
3 4
6. Production resumes and continues during migration
Option to keep legacy LUNs updated to match XIV LUNs
7. Disconnect legacy storage from XIV after migration is complete
8. Discard or repurpose legacy storage
DMX

Other Migration Choices
Host-Based Migration
AIX LVM Mirroring
VMware VMotion (not for RDM)
Unix DD command
Storage Virtualization
SVC / V7000
Volume Migration
Volume Mirror / Split
IBM Data Mobility Tools and Services

IBM XIV Performance

XIV Quality of Service (QoS) Overview
QoS Performance Class feature

Leverages existing capability already deployed in SVC
Provides a means of restricting system resources for serving I/O requests from specified
hosts/applications
Ensures performance for critical applications by limiting performance of less critical hosts/applications
Typical use case would be to separate Development/Test from Production
Implementation is enforced at the Interface Node level
Ensures cache is not consumed by runaway applications
Individual hosts can optionally be added to one of four client created QoS Performance
Classes
Each class can set max rates for IOPS and/or bandwidth (BW)
Each Interface Node enforces the specified max rate for all hosts associated with the
corresponding QoS Performance Class
A particular host can appear in at most one QoS Performance Class
A host that is not part of a QoS Performance Class is not subject to rate limitations

Achieving Best Performance from XIV
Host side vs. Storage side configuration

One of the real benefits running on XIV storage is directly related to way XIV
distributes data
Based on the above, there is very little an end user can or should do to fine-tune
the XIV
Legacy Architectures
RAID Groups
LUNs and MetaLUNs
Host Volumes
Meta-
LUN
LUNs /oracle LUN /oracle
Disk Vols
RAID
groups

XIV Host Attachment
Hosts
Defined to manage volume access (mapping)
Volumes can be mapped to 1 or more hosts
Volumes can be added and removed dynamically
3 host types
Default
HP-UX
z/VM
Host Ports
Ports are defined for hosts
Can be FC or iSCSI
Defined by host WWPN or iSCSI Name
Server Cluster
Group of hosts
Assign volumes to clusters for shared access

Achieving Performance: Host Side - Zoning
If a host has the ability to spread the load between more

than one path, utilizing multiple paths to multiple
modules will engage more resources on the XIV Grid
and therefore yield better performance.
Cache is also distributed
No advantage in using fewer interfaces
More interfaces utilize more CPUs for serving I/O
More interfaces evenly utilize the backend interconnects
More interfaces assures consistent performance even
through failure of an interface

XIV Host Zoning General Recommendation for Performance and BW
Redundant and Highly available configuration
Server HBA ports zoned to 3 XIV interface modules (or less if necessary)
Total of 6 paths. Allows for a wider combination of zoning patterns
Still good bandwidth, max parallelism, good XIV-port queue depth consumption

Host Zoning
When possible, engage the same zoning template/schema for all hosts
No need to manually balance the load via zoning
Balancing will happen naturally via combination of Host multipathing and XIV Grid structure
Always keep single initiator per zone
Multiple targets per zone can improve manageability
RoundRobin or similar algorithms offer good performance and low host overhead
Keep It Simple!

XIV Host Multipathing
XIV uses native multipathing (MPIO)

No additional charge
Eliminates concerns about interoperability with
OS upgrades
9
8
Use round robin 7
XIV enables large depths to exploit parallelism 6

5
of XIV grid 4
Symantec Veritas DMP is also supported

XIV Host Attachment Kits
XIV Host Attachment Kits (HAK)

No charge
Available for most platforms
Required for support when available
Easy install, consistent look & feel across
OSs
Validates patches and FC/iSCSI/HBA driver
versions
Sets up multipathing
Adjusts system tunables for performance (if
necessary)
Provides additional Utilities
Automatically define server to XIV from
server
Correlate OS disk names with XIV names
Automatically collect Diagnostics

Host Side - Queue Depth
Host queue depth essentially controls how much data is allowed to be in flight onto the SAN from the host
HBAs
XIV algorithms are more efficient when I/O requests are coming in parallel
Queue depth becomes important factor in maximizing XIV performance
Large queue depth settings are recommended
64 is a reasonable starting point for most typical scenarios
QoS can be controlled via XIV QoS Classes
HBA queue depth can also assist in controlling unruly servers

Host Side Number of LUNs and Sizes
Generally, with XIV there is no need to create a large number of small LUNs
That is a legacy limitation based on # disks, disk types, RAID groups, etc.
Goal is obtain best performance and maximum disk layout for each LUN
XIV will spread the data on all the drives regardless of the size of the LUN
On special configurations
Host Applications/OS might require more LUNs in order to maximize parallelism and
increase Data IO queues. E.g. VIOS limits queue depth at 32
As a rule of thumb, if the application needs to use multiple LUNs in order to allocate or
create multiple threads to handle the I/O, then use multiple LUNs
If the application is sophisticated enough to define multiple threads independent of the
number of LUNs, or the number of LUNs has no effect on application threads, then there is
no compelling reason to have multiple LUNs
Less, Larger LUNs!

Achieving Best Performance from XIV with Oracle
Oracle practices
Maximize multi-threading tasks
No need to configure many LUNs for data files
Always separate data LUNs from log LUNs into separate volume groups
Create and mount Redo-log FS at 512KB, others are fine at 4KB
Use the backup/recovery strategy to identify tablespaces that can share same LUNs
Make sure database is set to support AIO, CIO, buffered JFS/NTFS IO
Take advantage of database Parallel Execution features:
Parallel Query, Parallel DML, Parallel DDL, Parallel Recovery, Parallel Replication
Apply the above DML features in a sensible manner
E.g. if it is known that a full scan tables will be better than direct index access
Imagine an OLTP environment performing full table scans?
Best suited for DWH environments
As much as possible, use large database buffers to enable pre-fetching
For DWH, large R/W sequential IOs (128K-1MB) are optimal
Asynchronous I/O is recommended for an Oracle database
Oracle Configuration Best Practices ASM and XIV
ASM is Oracles storage management solution

An alternative to conventional volume managers, file systems, and raw devices
An ASM disk group is a collection of disks that ASM manages as a unit.

Content of files that are stored in a disk group is striped across all disks in the disk group
When configuring Oracle database

using ASM on XIV, as a rule of thumb,
to achieve better performance and
Data Load
create a configuration that is easy to Tim e Table Scan
manage use: Create Index
1 or 2 XIV volumes to create an Merge
ASM disk group

8M or 16M allocation Unit (stripe)
size
l
vo
8K
1M
8M
8M
8M
4M
4M
_1
12
_6
_6
l_
l_
l_
l_
No
vo
vo
vo
vo
l_
l
vo
vo
vo
_1
_1
_2
_6
_1
_2
_1
M
AS
AS
AS
AS
M
AS
AS
AS

XIV and SAP
There are two aspects for storage system sizing:

Capacity and performance
To estimate I/O profile and size storage for SAP environment:
Quicksizer tool estimate I/O profiles for planned SAP installations
Use actual IO/s performance measurements in existing installation
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 times performance constraints for an SAP ERP application:
between 5 and 7 ms - expected
between 10 and 15 ms - considered good
above 20 ms - considered as performance bottleneck
beyond of 30 ms - system does not behave as expected to the users

XIV Performance Sizing for SAP
XIV Gen2 delivers:

25K to 30K IOPS, Response Times of 10-15 ms
60K IOPS where Response Times of 30ms+ are acceptable

IBM has XIV/SAP customers that maintain the 60K+ IOPS with RT < 15ms
XIV Gen3 delivers:

Up to 65K IOPS with a Response Rime between 10 and 12 ms
Up to 100k IOPS where Response Times up to 30 ms are acceptable
In general, we see 2x improvement in SAP OLTP workloads on Gen3

Exchange 2010 Architecture Perfect fit for XIV!
Major Architecture Changes of Exchange 2010
Strongly Influences Storage Decision
HA/DR planning based on DAGs (Database Availability Groups)
New IO Pattern and Substantial IO Consolidation

No more Throughput (IOPS) centric, but Bandwidth Focus
Moving away from multiple small random IOs to fewer sequential larger IOs
32KB+ blocks w/larger sequential IOPS
Optimized for Large Mailboxes (2,5,10GB+) and Archive Mailboxes
Sensitivity of Rebuilt Overhead, hardware striping and manageability
Enabling Distributed Data Stores

ESRP 2010 (Exchange)
Storage # of mailboxes IOPS per # of # of disks/type Capacity MBox IOPS / Cost of

Vendor /size mailbox servers Utilization spindle / 1GB Solution
Capacity
XIV 1TB 40,000 / 1GB 1 8 360 / SATA 1TB 7.2K 63% 111 $$
Disks
XIV 2TB 40,000 / 3.5GB 0.18 10 360 / SATA 2TB 7.2K 88% 70 $$
Disks
XIV Gen3 2TB 120,000 / 1GB 0.13 24 360 / SAS 2TB 7.2K 88% 43.3 $$
EMC Clariion 60,000 / 1GB 0.18 36?! 480 SAS 600GB 10K 66% 22.5 $$$$
EMC VMax 100,000 / 2GB 0.14 20 880 / SATA 2TB 7.2K 45% 32 $$$$$
HDS 68,000 / 1GB 0.12 32 480 SAS 450GB 15K 44% 25.5 $$$$
HP EVA 9000 / 1.5GB 0.3 6 160 / SAS 450GB 15K 66% 25.3 $$
HP P9500 20,000 / 1.5GB 0.18 12 336 / SAS 300GB 10K 63% 16 $$
Netapp 12,000 / 2GB 0.10 4 64 / SATA 1TB 7.2K 39% 38 $$

IBM XIV and VMware

IBM XIV and VMware Integration
XIV vCenter plug-in VMware vCenter
Manage volume provisioning and resizing

XIV Plug-In
Display system and volume information
Automatically set multipathing policy
Receive XIV events and alerts
App App App App
OS OS OS OS
vStorage for Array Integration (VAAI)
VMware vSphere
Off-loads VMFS locking to XIV
Uses XIV for volume cloning
Uses XIV to zero out new volumes
vStorage APIs for Storage Awareness (VASA)

Profile driven storage direction
Storage Replication Adapter (SRA)

Coordinate recovery with VMware Site Recovery Manager (SRM)
See the XIV VMware Toolbox for white papers, clips, and case studies covering XIV storage and VMware

IBM XIV Monitoring and Events

XIV Ease of Administration
Extreme
Ease-of-Use
Breakthrough GUI
Exceptional ease of use
Powerful management capabilities
Easy, rapid provisioning
Minimal administration
Minimal training required

XIV GUI
Download and install Java client on:
Windows (32 or 64 bit) 2000, ME, XP, Server 2003, Vista, 7, 2008
Linux(32 or 64 bit) Red Hat 5.x or equivalent
AIX 5.3, 6.1
Solaris (Sparc 32 bit, X86 64 bit) V9, V10
HPUX 11i v2, 11i v3
Mac OS X 10.6
GUI actions translated into XCLI commands and sent to XIV system via SSL
XCLI commands also logged where GUI is running for easy script creation
Anyone can download GUI and run in Demo Mode
http://www-
933.ibm.com/support/fixcentral/swg/selectFixes?parent=ibm~Storage_Disk&product=ibm/Sto
rage_Disk/XIV+Storage+System+%282810,+2812%29&release=3.0&platform=All&function=all

GUI V3.1 Demo Mode Now Includes Gen3 and SSD
http://www-
933.ibm.com/support/fixcentral/swg/selectFixes?parent=ibm~Storage_Disk
&product=ibm/Storage_Disk/XIV+Storage+System+%282810,+2812%29&r
elease=All&platform=All&function=all

XIV All Systems Panel Bubble Indicators
Additional bubble indicators in the All-Systems view:
Number of volumes
Number of hosts

XIV Storage Pools
Soft Grey Hard Grey blue Snap grey hatched

Volumes Size Volumes Committed
Used by volumes Used Volumes Bright Blue
Snapshots size Snapshots Committed
Used by Snapshots Used Snapshots (Bright Blue hatched)
XIV Integrated Event and Monitoring Tools
Events
Logging
SNMP alerts and E-mail notifications
Escalation capabilities and filtering
Performance
IOPS, latency, bandwidth
Link utilization
System, pool, volume level, host/HBA
Export to CSV file
Capacity
Trending for used and allocated storage
By volume or pool
Export to CSV file
Provides reporting found in enterprise reporting

packages at no additional cost

XIV Storage: Events Log

XIV Storage: Performance Monitoring

XIV Mobile Dashboard iPad app
Download
http://itunes.apple.com/us/app/ibm-xiv-mobile-dashboard/id465595012?mt=8
Info
http://aussiestorageblog.wordpress.com/2011/10/06/ibm-xiv-mobile-dashboard-is-in-
the-apple-store/
Available now
Real-time performance statistics
Similar to XIVTOP
Coming Next
Alerting & monitoring
Provisioning

XIV Mobile Dashboard iPhone app
Login
System view
For Demo Mode

IP addr: demo
user: demo
password: demo
Download
http://itunes.apple.com/us
/app/ibm-xiv-mobile-
dashboard-
for/id503500546?mt=8

XIV Command Line Interface (XCLI)
Automatically installed with GUI
May be installed without GUI on Linux, AIX, and Solaris
Basic mode
Login (IP address and userid/pw) required for each command
xcli u userid p password m ip address vol_delete vol=p3_01 y
Additional output formatting options
- r option identifies file containing XCLI commands (enables use with shell scripts)
Interactive mode
Launched from
Desktop Icon
XIV GUI All Systems Panel
XIV System Panel
Login (IP address, userid/pw, XIV management IP address) provided once per session
>> prompt for XIV command
Command and argument completion (via tab key)
Reference documentation
XCLI Utility User Manual utility commands executed on client (help, formatting, defining XCLI configuration/login)
XCLI Reference Guide commands to be passed to XIV system for execution

IBM XIV Gen3 and SSD

XIV Gen3 Technology Highlights
20X more internal bandwidth

Using InfiniBand
Over 2X more external bandwidth

With 8 Gb/sec FC ports and over 3x more iSCSI ports (6-22)
New motherboards and processors

2x disk bandwidth, 60 cores, 120 hyper-threads per rack
50% more cache capacity

Up to 360GB/system, (24GB per module)
SSD ready
Optional cache upgrade of up to 6.0TB
Announced July 12, 2011

Generally available September 8, 2011

XIV Storage - Smarter by Design
Gen2 Gen3
Ethernet Interconnect InfiniBand Interconnect 6TB SSD
Option
Capacity: 24-161TB Capacity: 54-161-243TB
Switches
Switches
Max Memory: 240GB Max Memory: 360GB
Max FC ports: 24 x 4Gb/s Max FC ports: 24 x 8Gb/s
Max iSCSI ports: 6 x 1Gb/s Max iSCSI ports: 22 x 1Gb/s
iSCSI ports with 6 modules: 0 iSCSI ports with 6 modules: 10

Interface Modules
Disk Type: SATA Disk Type: SAS, SSD
Data Modules
UPS units

XIV SSD Solution
High capacity SSDs used as secondary read cache

400 GB enterprise-class SSD device added to each module
6 TB of cache per full rack
8
Housed in PCI caddy in rear of module 6
Scales with the system 6 to 15 SSD drives 4

2
Must be added to all modules together
0
XIV SSD is a transparent read cache, not a separate tier
No change to system usable capacity
Zero management, zero tuning
Real-time cache algorithm (not policy-based)
Immediate performance improvement
Available to all Gen3 systems
Gen3s already at customer locations
Non-disruptive upgrade on existing XIV
New orders

XIV Generation Comparison
XIV XIV Gen3
2810/2812-A14 2810/2812-114
Drives 72-180 72-180
Interconnect Ethernet InfiniBand
Disk Drives (7200 RPM) SATA (1 TB or 2 TB) SAS (2 TB or 3 TB)

Number of disk drives
72/180 72/180
(min/max)
SSD capacity per module N/A 400 GB
Max Capacity w/1 TB drives 79 TB N/A
Max Capacity w/2 TB drives 161 TB 161 TB
Max Capacity w/3 TB drives N/A 243 TB
Max FC ports 24 24
Max iSCSI ports 6 22
Max iSCSI ports in 6-module N/A 6
Max number of CPU cores 84 60

120 GB (8 GB per module)
360 GB (24 GB per module)
Max Memory 240 (16 GB per module)
DDR3
DDR2
Max cache-to-disk bandwidth 240 Gb/sec 480 Gb/sec
E5410 Intel Quad Core E5620 Intel Quad Core
Processor
XEON 2.33 GHz XEON 2.4 GHz
Host FC Adapters 4 Gb/sec 8 Gb/sec
Host iSCSI Adapters 1 Gb/sec 1 Gb/sec

XIV Gen3 - Ordering Information
Machine type
2810 - 1 year warranty
2812 - 3 year warranty
XIV Gen2 model number is A14
2810-A14
2812-A14
XIV Gen3 model number is 114
2810-114
2812-114
Features that are the same
Power solutions and line cords
Cables
Unit indicators
Attachment indicators
Certifications and labels
CoD term limits
Initial capacity indicators
XIV Gen3 uses the T42 rack options

f/c 0200 - Height/Weight reduction
Modules 12-15 removed
Rack ship weight approx. 2100 lbs (passenger elevator ready)
f/c 0080 - Ruggedized rack
Earthquake protection
Front and rear brace
Concrete floor bolts
f/c 0082 - Rear water-cooled door

XIV Rack Configurations
Full Rack 79/161/243 TB Blanks

15 modules
180 1TB / 2TB / 3TB Nearline disks

120GB/240GB/360GB memory
24 4GB/8GB FC ports
22 iSCSI ports
Partial Rack 27/55/84 TB

6 modules (9, 10, 11, 12, 13, 14)
72 1TB / 2TB / 3TB Nearline disks
48GB/96GB/144GB memory
8 4GB/8GB FC ports
0-22 iSCSI ports

XIV How Many Modules?
Data storage capacity
Performance capacity
Disk Magic modeling
Application experience
Host interfaces
Rack Configuration
Total number of modules 6 9 10 11 12 13 14 15
(Configuration type) partial partial partial partial partial partial partial full
Number of data modules 4 5 6 6 7 7 8 9
Number of active interface modules 2 4 4 5 5 6 6 6
Module 9 state Disabled Disabled Enabled Enabled Enabled Enabled Enabled
Module 8 state Enabled Enabled Enabled Enabled Enabled Enabled Enabled
Module 7 state Enabled Enabled Enabled Enabled Enabled Enabled Enabled
Module 6 state Disabled Disabled Disabled Disabled Disabled Enabled Enabled Enabled
Module 5 state Enabled Enabled Enabled Enabled Enabled Enabled Enabled Enabled
Module 4 state Enabled Enabled Enabled Enabled Enabled Enabled Enabled Enabled
Number of disks 72 108 120 132 144 156 168 180
Net capacity 1TB drives (rounded down in full TB) 27 TB 43 TB 50 TB 54 TB 61 TB 66 TB 73 TB 79 TB
FC ports 8 16 16 20 20 24 24 24
iSCSI ports (A14/Gen3) 0/6 4/14 4/14 6/18 6/18 6/22 6/22 6/22
Memory A14 (8/16 GB per module) 48/96 72/124 80/160 88/176 96/192 104/208 112/224 120/240
Memory Gen3 (24 GB per module) 144 216 240 264 288 312 336 360
IBM System StorageTM 2011 IBM Corporation 86

XIV Storage Innovation
Gen3 Evolution of the Revolution
Gen2 Profile Gen3 Profile

High performance Ultra-High Performance
Lower cost/TB Up to 4X increase
Lower entry point SSD cache upgradeable
27 TB usable Higher entry point capacity
55 TB usable
20% less power consumption

20% less heat output
33% less noise
Both deliver
60% lower TCO than competition
Broad workload affinity
Radical Simplicity
Fully autonomic data placement, self-healing
Advanced features out-of-the-box

Outstanding Performance Across Applications (Gen2 Vs. Gen3)
Microsoft Exchange Mailboxes Oracle Data Warehouse (IOPS)

Requires latency under 20 ms Oracle DHW Workload
ESRP-Storage test 20,000 60,000 55,000 115,000
XIV XIV Gen3 XIV XIV Gen3
SAS Business Analytics Workload Microsoft HyperV Simulation (IOPS)

Analytics reports created 200GB dataset
Simulated via Swingbench load generator
60% write activity
70 207 13,605 37,856
Transaction Processing (IOPS) Sequential Reads (MB/sec)

Mixed read / write workload System Bandwidth
33,000 66,000 3,034 10,300

File and Print Services (IOPS) Sequential Writes (MB/sec)

Mixed file size workload System Bandwidth
XIV Gen3 also had 42,000 125,000
50% lower latency XIV XIV Gen3 1,542
XIV
6,788
XIV Gen3
Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput 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 improvements equivalent to
the performance ratios stated here.

Outstanding Applications Performance with SSD Caching
DB2 Brokerage (IOPS) WebSphere Datastore (IOPS)

Heavy Random Brokerage Web 2.0 OLTP Workload
90/10, Mixed block IO 80/20/4k
84% Random Read Miss
Core ERP (IOPS) Medical Record App Server (RT)

CRM and Financial DB Workload Healthcare EMR Workload
70/30/8k 100% random IO
Performance is based on measurements and projections using standard IBM benchmarks in a controlled environment. The actual throughput 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 improvements equivalent to the
performance ratios stated here.

Enhanced TPC Support for XIV
TPC 4.2.2 provided enhanced support for XIV with the following functions
SAN Planner
Provide XIV provisioning with performance history for an end-to-end provisioning recommendation and action
Performance Analytics
Identify hotspots
Migrate data from one array to another to improve overall throughput when using SVC
Announced Oct 11, 2011; Electronic General Availability Oct 14, 2011
Previous TPC support for XIV
TPC 4.2 (August 2010)
Management and data collection
Utilization of XIV Native API for improved performance and stability
Storage capacity reporting
End to End Topology View and Data Path Explorer
Alerting
Configuration History (changes)
Performance Monitoring
Performance thresholds to generate alerts and trigger actions
Performance rollup for multiple systems
XIV 10.2.4 and TPC 4.2.1 fixpack 2 provide additional performance metrics
Storage provisioning
SAN Planner (Space only)
TPC 4.1 (May 2009)
CIM Agent on XIV developed and used by TPC
Asset, health and capacity reports

XIV / TPC Additional Information
TPC for Replication (TPC-R) Support
TPC-R 4.2.2 provided XIV Gen 2 support in October 2011
Details of the support for Snapshot, Synchronous and Asynchronous mirroring can be found at:
http://www-03.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS4807
http://partners.boulder.ibm.com/src/atsmastr.nsf/WebIndex/PRS4807
http://www.ibm.com/support/techdocs/atsmastr.nsf/WebIndex/PRS4807
TPC-R 4.2.2 FP1 added support XIV Gen 3 in December 2011

TPC-R 4.2.2 FP2 is planned to support for XIV Gen 2 to Gen 3 replication in 2Q12
FlashCopy Manager 3.1 supports XIV Gen3

http://www-01.ibm.com/support/docview.wss?uid=swg21567512

XIV Capacity On Demand
A14 models Gen3 (114 models)

Machine is sold with full 15 Machine is sold with up to 3 more modules of useable capacity
modules than activated.
Client purchases initial Client purchases capacity in fixed increments of up to 10.7 TB
capacity of fewer modules (varies)
Machine is not aware that it Machine is not aware that it is in CoD mode
is in CoD mode
Client can use the capacity whenever they want
Client can use the on-
Every machine reports consumed capacity back to IBM every
demand capacity whenever
day (via e-mail)
they want
Consumed capacity is sum of all created volumes (soft size)
Agrees to purchase full
plus sum of all snapshot reserves
system capacity within 12
months Use Soft Pool size to control space usage
Monitor with cod_list command to display consumed
capacity
XIV Gen3 Capacity on Demand- Rules
All valid gen3 configurations supported

Allow 1, 2, or 3 un-activated modules (can only configure up to 3 more
CoD modules than are activated)
12 module CoD configuration - CoD capacity must be activated on 9, 10, or 11
modules
9 module CoD configuration - CoD capacity on 6, 7, or 8 modules must be activated
6 module CoD configuration - CoD capacity on 3, 4, or 5 modules must be activated
When you fail to maintain the 1, 2, or 3 un-activated module buffer, you
EXIT the CoD program
12 module configuration, if you activate the 12th module, you must also
order 1, 2, or 3 more CoD data modules (f/c1146) or you exit the CoD
program
Once out of CoD program, you can MES regular modules f/c1125 and
f/c1126 to continue population

More Rules
Clients MUST agree to enable, and support, IBM XIV call home feature
Daily email heartbeat that includes consumed capacity data
Warranty for all physically installed modules at code-20 date
Remember they are in fact being used
Adding more CoD modules will:
Effectively create a rolling CoD term
Starts the warranty period for each of these

IBM XIV Summary

XIV -- Standard Features
Virtualized grid storage

Data distribution across all drives Raid
No RAID groups to manage Groups
Automatic load balancing
Consistent performance
No manual tuning Tiered

Thin Provisioning
Disk
High Performance, flexible Snapshots
Remote Replication
Complex
Java based management
Mgmt.
Innovative data migration

Improved Capacity Utilization = TCO Control
XIV sold as USABLE capacity

NO lost capacity due to : spares, special system areas,
volume set asides for replication, etc.
Capacity usage easy to monitor

Complete system, storage pool, or volume
XIV is fully virtualized

Configured with a single disk type and no RAID
groups to minimize islands of capacity
No physical disk binding
THIN provisioning standard
Designed to perform well at >90% Capacity Utilization

XIV Customer Driven, Market Proven
Thousands of XIV clients worldwide are enjoying the benefits of:
Improved storage efficiency and data protection
Reduced complexity
Great service for a wide variety of apps and workloads

IBM XIV Additional Resources

XIV WIKI
http://w3.ibm.com/connections/wikis/home/wiki/W069af4782acc_42c5_bf26_8a6ba4387190/page/XIV%20Storage%20System?lang=en

Gen 3 Tech Sales Portal
http://w3.ibm.com/connections/wikis/home?lang=en#/wiki/W069af4782acc_42c5_bf26_8a6ba4387190/page/XIV%20Gen3%20Tech%20Portal

Client reference DB search fro XIV
http://w3-01.ibm.com/sales/ssi/apilite?appname=crmd&mostrecentsort=yes&crv=no&additional=summary&alldocs=TRUE&infotype=CR&others=RFCS RFVI&contents=XIV

IBM Success Stories
http://www-01.ibm.com/software/success/cssdb.nsf/topstoriesFM?OpenForm&Site=corp&cty=en_us

YouTube

Latest Pre-sales Checklist Documentation
http://w3-03.ibm.com/support/assure/assur30i.nsf/WebIndex/SA830

XIV Documentation
XIV Information Center (All) http://publib.boulder.ibm.com/infocenter/ibmxiv/r2/index.jsp

XIV product information and documentation
Theory of Operation how it works, high level functional specification
XCLI Utility User Manual utility commands executed on client (help, formatting, defining XCLI configuration/login)
XCLI Reference Guide commands to be passed to XIV system for execution
Redbooks www.ibm.com/redbooks (All)

IBM XIV Storage System: Architecture, Implementation, and Usage
IBM XIV Storage System: Copy Services and Migration
IBM XIV Host Attachment and Implementation
IBM XIV Storage with VIOS and IBM I
Techdocs w3.ibm.com/support/techdocs (IBM)

Techdocs www.ibm.com/support/techdocs (All)
Whitepapers, flashes, ATS presentations and training materials
System Storage Interoperation Site (SSIC, Interoperability Guide)

http://www-03.ibm.com/systems/support/storage/config/ssic/displayesssearchwithoutjs.wss?start_over=yes

XIV Capacity and Chargeback Reporting Tool
http://w3.ibm.com/connections/communities/service/html/communityview?communityUuid=78687be9-c415-4d35-8087-
176cf18d450d#fullpageWidgetId=Wf004d4520496_469b_a1d5_53a3efcf58dd&file=ea776b63-7289-4052-95eb-3ec5da7c53ad
XIV Capacity Report script - provides automated charge-back reports

Storage Efficiency Calculator
http://www-304.ibm.com/partnerworld/wps/storage/efficiency/calculator.html

TCOnow Tool
https://w3-03.ibm.com/sales/competition/compdlib.nsf/weball/D0AB8D8A124B4E7D0025711D00465819?OpenDocument

Competitive Tools
https://w3-03.ibm.com/sales/competition/compdlib.nsf/pages/tools#_Brands

XIV Downloads (GUI, HAK, Agents VSS, vCenter Console)
http://www-01.ibm.com/support/search.wss?q=ssg1*&tc=STJTAG+HW3E0&rs=1319&dc=D400&dtm

XIV Code Download
https://steamboat.boulder.ibm.com/webapp/iwm/int/reg/pick.do?lang=en_US&source=IIPxiv

Lab Services Training Offerings
http://www-03.ibm.com/systems/services/training/storage/index.html

Power/Heat/Weight A14 versus Gen3
A14 1TB disks 6 9 10 11 12 13 14 15
kVA Typical/Max 2.9 / 3.4 4.2 / 5.0 4.7 / 5.5 5.2 / 6.1 5.7 / 6.7 6.2 /7.2 6.7 / 7.8 7.2 / 8.4
BTU/hour 11.7 17 18.9 20.8 22.8 24.7 26.6 28.5
Weight (KG) 629 713 740 767 794 821 848 884
A14 2TB disks 6 9 10 11 12 13 14 15
kVA Typical/Max 2.8 / 3.1 4.5 /4.5 4.4 / 4.9 4.7 / 5.4 5.1 / 6.2 5.5 / 6.2 5.9 / 6.6 6.2 / 7.1
BTU/hour 10.6 15.4 16.9 18.3 19.7 21.2 22.6 24.1
Weight (KG) 629 713 740 767 794 821 848 884
114 2TB disks 6 9 10 11 12 13 14 15
kVA Typical/Max 2.5/2.8 3.7/4.2 4.1/4.6 4.5/5.0 5.0/5.4 5.4/5.8 5.8/6.3 6.2/6.7
BTU/hour 10.4 15.6 17.3 19 20.7 22.5 24.2 26
Weight (KG) 795 879 907 935 964 992 1020 1048
114 3TB disks 6 9 10 11 12 13 14 15
kVA Typical/Max 2.5/2.8 3.7/4.2 4.1/4.6 4.6/5.1 5.1/5.6 5.5/6.0 5.9/6.5 6.3/7.0
BTU/hour 12.2 18.3 20.2 22.2 24.2 26.3 28.3 30.4
Weight (KG) 795 879 907 935 964 992 1020 1048

XIV Gen3 with 2 TB Drives Capacity on Demand
6 Physical 9 Physical 10 Physical 11 Physical 12 Physical 13 Physical 14 Physical 15 Physical

Modules Modules Modules Modules Modules Modules Modules Modules
Maximum Capacity --> 55700 88000 102600 111500 125900 134900 149300 161300
Capacity per CoD Activation --> 9283 9778 10260 10136 10492 10377 10664 10753
3 CoD Activations --> 27850
6 CoD Activations --> 55700 58667
8 CoD Activations --> 78222 82080 81091
9 CoD Activations --> 88000 92340 91227 94425
10 CoD Activations --> 102600 101364 104917 103769
11 CoD Activations --> 111500 115408 114146 117307
12 CoD Activations --> 125900 124523 127971 129040
13 CoD Activations --> 134900 138636 139793
14 CoD Activations --> 149300 150547
116 IBM System StorageTM 9-Oct-14 2012 IBM Corporation

XIV Gen3 with 3 TB Drives Capacity on Demand
6 Physical 9 Physical 10 Physical 11 Physical 12 Physical 13 Physical 14 Physical 15 Physical

Modules Modules Modules Modules Modules Modules Modules Modules
Maximum Capacity --> 84100 132800 154900 168300 190000 203600 225300 243300
Capacity per CoD Activation --> 14017 14756 15490 15300 15833 15662 16093 16220
3 CoD Activations -->

42050
8 CoD Activations --> 118044 123920 122400
9 CoD Activations --> 132800 139410 137700 142500
10 CoD Activations --> 154900 153000 158333 156615
11 CoD Activations --> 168300 174167 172277 177021
12 CoD Activations --> 190000 187938 193114 194640
13 CoD Activations --> 203600 209207 210860
14 CoD Activations --> 225300 227080
117 IBM System StorageTM 9-Oct-14 2012 IBM Corporation

IBM XIV Gen3 Overview

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

IBM XIV Gen3 Overview

Загружено:

Авторское право:

Доступные форматы

XIV Essentials:

Everything you wanted to know about XIV!

2012 IBM Corporation

XIV hardware and architecture

What this means for our customers:

Established IBM support and services

3 IBM System StorageTM 2012 IBM Corporation

State of the Business

Clients with 2 PB+ (usable): 16

4 IBM System StorageTM 2012 IBM Corporation

5 IBM System StorageTM 2012 IBM Corporation

IBM XIV Storage System is

We are exceeding our SLAs and

6 IBM System StorageTM 2012 IBM Corporation

Thin Provisioning, Snapshot, Remote Mirroring included at No Charge

Ease of use Management Graphical User Interface (GUI)

8 IBM System StorageTM 2012 IBM Corporation

Disk Configurations to Manage

With XIV, manage storage capacity - NOT technology!

10 IBM System StorageTM 2012 IBM Corporation

Fully virtualized SAN based on grid 5 9s+

11 IBM System StorageTM 2012 IBM Corporation

iSCSI XIV Module

Module XIV Module

12 IBM System StorageTM 2012 IBM Corporation

Host XIV Module Huge internal bandwidth

Zero tuning or manual intervention

13 IBM System StorageTM 2012 IBM Corporation

Redesign after changes iSCSI XIV

14 IBM System StorageTM 2012 IBM Corporation

Grid scaling improves performance

Grid scaling reduces administrative tasks

No islands of orphaned capacity

Quality of Service capabilities

Oracle Hardware Bound

16 IBM System StorageTM 2012 IBM Corporation

Each logical volume is spread across all drives

17 IBM System StorageTM 2012 IBM Corporation

18 IBM System StorageTM 2012 IBM Corporation

Traditional Arrays IOPS profile: Unbalanced Disk Layout

XIV IOPS / Balanced Disk Layout

19 IBM System StorageTM 2012 IBM Corporation

Data Module 1 Data Module 2

Data Module 3 DataNode

Component phased out

Auto Rebalancing during Data Module 2

Data Module 3 Data Module 4

21 IBM System StorageTM 2012 IBM Corporation

Enterprise-class, Robust Features All Included

22 IBM System StorageTM 2012 IBM Corporation

23 IBM System StorageTM 2012 IBM Corporation

Data Module 3 Data Module 4

24 IBM System StorageTM 2012 IBM Corporation

Restores are instantaneous since they only manipulate

Data Module 3 Data Module 4

25 IBM System StorageTM 2012 IBM Corporation

Source volumes are placed in a Consistency Group Storage Pool

Within a single Storage Pool Consistency Group

Consistent Snapshot Group is created from Consistency Group Source Source

A volume may be in 1 Consistency Group

Easy movement in and out of Consistency Group

Maximum of 256 Consistency Groups per system

For application consistency, XIV integrates with FlashCopy

26 IBM System StorageTM 2012 IBM Corporation