Xiv overview

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

Agenda
XIV hardware and architecture
Snapshots
Thin Provisioning
Replication
Data migration
© 2012 IBM Corporation2 IBM System StorageTM
Data migration
Performance
VMware integration
Monitoring
XIV Gen3 and SSD Update
Additional Resources

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
► 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 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
200
250
300
350
226226
256256
289289
348348
Usable Petabytes
0
50
100
150
11 11 33 1212 1818 3131
4646
7777
9595
128128
160160
209209
226226

“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
Sampling of XIV Installations
“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

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

IBM XIV Hardware and Architecture

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

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

XIV Module
XIV ModuleHost
Host
FC
Interconnect
iSCSI
Host
Data
Modules
Interface
Modules
SSD
SSD
XIV System Components
XIV Module
UPSUPS UPS
XIV Module
Interconnect
Data
Modules
Interface
Modules
SSD
SSD
Module
► CPU(s)
► Memory
► 12 disk drives
► Optional SSD (Gen3)
Interconnect
Full rack
► 15 Modules
Partial rack
► 6, 9-14 modules

Ground-breaking
Architecture Large Processing Power (Modules)
Host
Host
FC
XIV Module
12x 2TB/3TB SAS Disk, 24GB Cache & 1Quad Core
CPU
Huge internal bandwidth
High cache-to-disk bandwidth
Grid Architecture
Innovative and Powerful Caching
Aggressive, parallel pre-fetching
Variable block-size cache
Simpler cache management
Clustered Controllers
Other solutions… Massive parallelism for IO processing
Autonomic data layout across grid
InfiniBand interconnect
SSD
XIV Architecture Details
Internal
Connectivity
Host
iSCSI
Host
High cache-to-disk bandwidth
Module services only its own disksXIV ModuleXIV ModuleXIV ModuleXIV ModuleXIV Module
XIV ModuleXIV ModuleXIV ModuleXIV ModuleXIV Module
Higher cache hit-ratios
Consistent performance through workload changes
(peak or average)
Optional 6TB Read Cache Acceleration
Simpler cache management
RAID protections
Long RAID rebuilds
Require LUN/Disk Layout
Performance tuning
Disk Hot-Spots
Islands of storage
Active/Active IO parallel access
Zero tuning or manual intervention
SSD
SSD

Ground-breaking
Architecture Scalable and sustained high performance
Host
Host
FC
XIV Module
Unprecedented Resiliency
Manual intervention
Other solutions…
Minimum operations impact upon disk failure (<1%) or
module (<7%)
SSD
XIV Architecture Details (2)
Internal
Connectivity
Host
iSCSI
Host
Manual intervention
Redesign after changes
Capacity-only scalability
Performance tuning
Continual data movement
High impact after any failure XIV ModuleXIV ModuleXIV ModuleXIV ModuleXIV Module
Linear scalability on capacity and performance
XIV utilization always balanced regardless of
add/delete/resize LUNs
Automatic data rebalancing after new disk/module
additions
Automatic rebalancing even after a system component
failure or during rebuild
module (<7%)
SSD
SSD
SSD

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
► 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

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

XIV Solution Architecture
Each logical volume is spread across all drives
► Data is “cut” into 1MB “partitions” or “chunks” and stored on the disks
► XIV’s 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

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

XIV vs. Traditional Architecture – Disk Utilization
The result?
Traditional Arrays IOPS profile: Unbalanced Disk LayoutTraditional Arrays IOPS profile: Unbalanced Disk Layout
We go from this…To this…
XIV IOPS / Balanced Disk LayoutXIV IOPS / Balanced Disk Layout
IOPSIOPS
DisksDisks
IOPSIOPS
DisksDisks

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
Node 4
Data Module 2
Data Module 3
Data Module 1
[ hardware upgrade ]
Data Module 4
IB

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

Enterprise-class, Robust Features – All Included
Unique snapshot technology
Simple, dynamic QoS
Powerful synchronous and asynchronous mirroring
Powerful
Features
XIV Feature Summary
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

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

Volume
Pointer Map
Snapshot
Restores are instantaneous since they only manipulate
pointer maps. Any snap, regardless of order, can source
a restore.
XIV Snapshots - Restore
Data Chunks
Snapshot
Pointer Map
Snapshot
Pointer Map
Snapshot
Pointer Map
Data Module 2
Data Module 3
Data Module 1
Snapshot
Pointer Map
Snapshot
Pointer Map
IB

XIV Consistent Snapshot Groups
Crash or power-loss consistency across multiple volumes
► Dependent write consistency
Source volumes are placed in a Consistency Group
► Within a single Storage Pool
Consistent Snapshot Group is created from Consistency Group
A volume may be in 1 Consistency Group
Storage Pool
Consistency Group
Source
Volume
Source
Volume
A volume may be in 1 Consistency Group
Easy movement in and out of Consistency Group
Maximum of 128 volumes per Consistency 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
Snapshot Group
Snapshot
10am
Snapshot
10am

IBM FlashCopy Manager
Application
System
Application
Data
Local
Snapshot
Versions
Snapshot
Backup
FlashCopy Manager
Online, near instant snapshot
backups with minimal
performance impact
High performance, near
Online, near instant snapshot
backups with minimal
performance impact
Storage Manager 6
With Optional
TSM Backup
Integration
SVC
XIV
DS8000
Storwize
V7000
DS 3/4/5*
For IBM and non-IBM Storage
instant restore capability
Integrated with IBM Storage
Hardware
Simplified deployment
instant restore capability
Integrated with IBM Storage
Hardware
Simplified deployment
*VSS Integration

IBM XIV Thin Provisioning

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

What Does it Take to Provision XIV Storage?
1. Define a Storage Pool
► Thin or Thick Provisioning
► Size
2. Define Volumes in the Pool
VMware 20TB
► 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
Usage example -- Multiple storage pools
► Capacity isolation
● Capacity protection for ‘loved ones’
● Capacity limitation for ‘badly behaved’
● Different applications
● Different servers
● Different organizations
● Capacity chargeback
10TB
20TB
Storage Pools
● Capacity chargeback
► Different thin provisioning/regular provisioning
requirements
► Snapshot capacity isolation
Usage example -- Single storage pool
► Single application accesses the XIV system
► All volumes require a consistent set of Snapshots
► Maximum storage pool size
● 161TB/243TB with R11.1
9TB
40TB243TB

XIV Volume
Created from space in one pool
► Space allocation in 17GB increments
► May be presented in 512B blocks
All volume space is spread across ALL disk drives
► All volumes spread across all disk drives in mirrored 1MB chunks
► All volumes get full performance potential of entire XIV system
10TB
20TB
Storage Pools
34 3434
1013 1013
17 17
17
► All volumes get full performance potential of entire XIV system
Thick/thin provisioning depends on pool type
Easy, dynamic changes to both volumes and pools
► Increase/Decrease volume size
► Move volumes between pools
► Increase/Decrease pool sizes (hard, soft, Snapshot)
► Change pool thick/thin type
9TB
40TB
17
51
51
51v
51
51
51
51
5151
17 17
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
Mirrored volume
► Replication changes (activate, deactivate, change
roles) are taken for an individual volume
Target
Volume Mirror
Source
► Usage example – single volume with replication
requirements that do not fit a group
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
Mirrored CG

XIV Synchronous Replication -- Normal Operation
2
1
4
Application Server
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
3
Remote XIVLocal XIV

XIV Asynchronous Replication
3
1
2
Application Server
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)
2
Remote XIVLocal XIV

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

Basic XIV Replication Configurations
One local system to one remote system
► Most common configuration
M
S
M
Target
Simultaneous bi-directional (different volumes)
► Usage example – 2 active sitesM
S
M
Target
Target

Basic XIV Replication Configurations (2)
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
Target
Multiple local systems to one remote system (‘Fan in’)
► Usage examples:
● 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
Target
Target

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)
4
5
6
7
8
9
4
5
6
7
8
9
FC SAN
FC SAN
FCIP routers can be used (check SSIC)
WDMs can be used (ensure BB credits are sufficient)
XIV Gen2 <-> Gen3 fully supported
Site 2
Site 1 Target

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)
Understand link quality, latency and actual BW available for replication
► Use deployment experts to optimize solution
Target
Site 2
Local
Site 1
XIV Gen2 <-> Gen3 fully supported
4
5
6
7
8
9
4
5
6
7
8
9 IP Network
IP Network

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
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
1. Server is connected to legacy system & accessing legacy LUNs
2. Disconnect server from legacy system
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
Map legacy LUNs to XIV ‘host’
4. Start migration
XIV
Server
1
5 6
4. Start migration
XIV copies LUN sequentially
5. Connect server to XIV
Map new XIV LUNs to server
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
3 4

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
► 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
Legacy Architectures
• RAID Groups
• LUNs and MetaLUNs
• Host Volumes
LUN /oracleLUNs
Meta-
LUN
RAID
groups
/oracle
Disk Vols

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
► 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
Round–Robin or similar algorithms offer good performance and low host overhead
Round–Robin or similar algorithms offer good performance and low host overhead
Keep It Simple!Keep It Simple!Keep It Simple!Keep It Simple!

XIV Host Multipathing
XIV uses native multipathing (MPIO)
► No additional charge
► Eliminates concerns about interoperability with
OS upgrades
► Use round robin 7
8
9
► XIV enables large depths to exploit parallelism
of XIV grid
► Symantec Veritas DMP is also supported
4
5
6

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
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
● QoS can be controlled via XIV QoS Classes
● HBA queue depth can also assist in controlling “unruly” servers

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
Host Side – Number of LUNs and Sizes
► 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!Less, Larger LUNs!Less, Larger 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
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 Oracle’s 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
No_1volASM
_1vol_128K
ASM
_1vol_1M
ASM
_1vol_8M
ASM
_2vol_8M
ASM
_6vol_8MASM
_1vol_64MASM
_2vol_64M
Time
Data Load
Table Scan
Create Index
Merge
When configuring Oracle database
using ASM on XIV, as a rule of thumb,
to achieve better performance and
create a configuration that is easy to
manage use:
► 1 or 2 XIV volumes to create an
ASM disk group
► 8M or 16M allocation Unit (stripe)
size

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:
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
Vendor
# of mailboxes
/size
IOPS per
mailbox
# of
servers
# of disks/type Capacity
Utilization
MBox IOPS /
spindle / 1GB
Capacity
Cost of
Solution
XIV – 1TB
Disks
40,000 / 1GB 1 8 360 / SATA 1TB 7.2K 63% 111 $$
XIV – 2TB
Disks
40,000 / 3.5GB 0.18 10 360 / SATA 2TB 7.2K 88% 70 $$
XIV Gen3 2TB 120,000 / 1GB 0.13 24 360 / SAS 2TB 7.2K 88% 43.3 $$
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
► Manage volume provisioning and resizing
► Display system and volume information
► Automatically set multipathing policy
► Receive XIV events and alerts
vStorage for Array Integration (VAAI)
Off-loads VMFS locking to XIV
VMware vCenter™
XIV Plug-In
App
OS
VMware vSphere™
App
OS
App
OS
App
OS
► 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

Breakthrough GUI
Exceptional ease of use
Powerful management capabilities
Easy, rapid provisioning
Extreme
Ease-of-Use
XIV Ease of Administration
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
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
► 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
► Similar to XIVTOP
Coming Next
► Alerting & monitoring
► Provisioning

Login
System view
For Demo Mode
XIV Mobile Dashboard – iPhone app
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
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
Switches
Gen2
Ethernet Interconnect
Switches
6TB SSD
Option
Capacity: 24-161TB
Max Memory: 240GB
Max FC ports: 24 x 4Gb/s
Max iSCSI ports: 6 x 1Gb/s
iSCSI ports with 6 modules: 0
Capacity: 54-161-243TB
Max Memory: 360GB
Max FC ports: 24 x 8Gb/s
Max iSCSI ports: 22 x 1Gb/s
Gen3
InfiniBand Interconnect
UPS units
Data Modules
Interface Modules
Disk Type: SATA
Disk Type: SAS, SSD

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
► Housed in PCI caddy in rear of module
► Scales with the system – 6 to 15 SSD drives
► Must be added to all modules together
XIV SSD is a transparent read cache, not a separate tier
0
2
4
6
8
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
2810/2812-A14
XIV Gen3
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
(min/max)
72/180 72/180
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/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
Max Memory
120 GB (8 GB per module)
240 (16 GB per module)
DDR2
360 GB (24 GB per module)
DDR3
Max cache-to-disk bandwidth 240 Gb/sec 480 Gb/sec
Processor
E5410 Intel Quad Core
XEON 2.33 GHz
E5620 Intel Quad Core
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
– 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
►15 modules
►180 1TB / 2TB / 3TB Nearline disks
►120GB/240GB/360GB memory
►24 4GB/8GB FC ports
►22 iSCSI ports
Blanks
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
(Configuration type)
6
partial
9
partial
10
partial
11
partial
12
partial
13
partial
14
partial
15
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
© 2011 IBM Corporation 86IBM System StorageTM
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

XIV Storage Innovation
Gen3 – Evolution of the Revolution
Gen2 Profile
High performance
Lower cost/TB
Lower entry point
27 TB usable
Gen3 Profile
Ultra-High Performance
Up to 4X increase
SSD cache upgradeable
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
Both deliver…
60% lower TCO than competition
Broad workload affinity
Radical Simplicity
Fully autonomic data placement, self-healing
Advanced features out-of-the-box

SAS Business Analytics Workload
Analytics reports created
Simulated via Swingbench load generator
Microsoft HyperV Simulation (IOPS)
200GB dataset
60% write activity
Microsoft Exchange Mailboxes
Requires latency under 20 ms
ESRP-Storage test
Oracle Data Warehouse (IOPS)
Oracle DHW Workload
20,000
XIV
60,000
XIV Gen3
55,000
XIV
115,000
XIV Gen3
70 207 13,605 37,856
Outstanding Performance Across Applications (Gen2 Vs. 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.
XIV XIV Gen3 XIV XIV Gen3
33,000
XIV
66,000
XIV Gen3
3,034
XIV
10,300
XIV Gen3
42,000
XIV
125,000
XIV Gen3 1,542
XIV
6,788
XIV Gen3
File and Print Services (IOPS)
Mixed file size workload
XIV Gen3 also had
50% lower latency
Sequential Writes (MB/sec)
System Bandwidth
Transaction Processing (IOPS)
Mixed read / write workload
Sequential Reads (MB/sec)
System Bandwidth

DB2 Brokerage (IOPS)
Heavy Random Brokerage
90/10, Mixed block IO
84% Random Read Miss
WebSphere Datastore (IOPS)
Web 2.0 OLTP Workload
80/20/4k
Outstanding Applications Performance with SSD Caching
Core ERP (IOPS)
CRM and Financial DB Workload
70/30/8k
Medical Record App Server (RT)
Healthcare EMR Workload
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
● 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
Machine is sold with full 15
modules
Client purchases initial
capacity of fewer modules
Machine is not ‘aware’ that it
Machine is sold with up to 3 more modules of useable capacity
than activated.
Client purchases capacity in fixed increments of up to 10.7 TB
(varies)
Machine is not ‘aware’ that it is in CoD mode
A14 models Gen3 (114 models)
Machine is not ‘aware’ that it
is in CoD mode
Client can use the on-
demand capacity whenever
they want
Agrees to purchase full
system capacity within 12
months
Machine is not ‘aware’ that it is in CoD mode
Client can use the capacity whenever they want
Every machine reports consumed capacity back to IBM every
day (via e-mail)
Consumed capacity is sum of all created volumes (soft size)
plus sum of all snapshot reserves
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
► 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 MUSTMUST 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:
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
►No RAID groups to manage
Automatic load balancing
►Consistent performance
Raid
Groups
Tiered
►No manual tuning
Thin Provisioning
High Performance, flexible Snapshots
Remote Replication
Java based management
Innovative data migration
Tiered
Disk
Complex
Mgmt.

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
Improved storage efficiency and data protection
Thousands of XIV clients worldwide are enjoying the benefits of:
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
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
Modules
9 Physical
Modules
10 Physical
Modules
11 Physical
Modules
12 Physical
Modules
13 Physical
Modules
14 Physical
Modules
15 Physical
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
© 2012 IBM Corporation116 IBM System StorageTM 9-Oct-14
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

XIV Gen3 with 3 TB Drives Capacity on Demand
6 Physical
Modules
9 Physical
Modules
10 Physical
Modules
11 Physical
Modules
12 Physical
Modules
13 Physical
Modules
14 Physical
Modules
15 Physical
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
© 2012 IBM Corporation117 IBM System StorageTM 9-Oct-14
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

Xiv overview

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Xiv overview

Similar to Xiv overview (20)

Recently uploaded

Recently uploaded (20)

Xiv overview