xiv overview

XIV Essentials:Everything you wanted to know about XIV!

© 2012 IBM Corporation

[email protected]

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 31314646

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

2006XIV 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 2008XIV Gen22810-A14V10 S/W

15 Module1TB DDM4Gb FC

Mar 2009XIV Gen2

6 – 15 Module

Oct 2009XIV Gen2R10.2 S/W

Async Mirroring

Feb 2011XIV Gen2

V10.2.4 S/WVMware VAAI

QoSOffline Init

3.0 3.1

Oct 2011XIV Gen3R11.0.1

3TB Drives243TB CapacityVMware VASA

3.01


Jan 2008IBM

Acquisition

Dec 2008XIV Gen26 Module

Jul 2009XIV Gen2V10.1 S/W

Faster CPU Concurrent Code LoadCapacity on Demand2812-A14 for warranty

LDAPGUI Enhancements

Apr 2010XIV Gen2

V10.2.1 S/W2TB Drives

240GB Cache161TB

capacity

July 2011XIV Gen3InfiniBand

New Modules360GB Cache

8Gb FC

Thin Provisioning, Snapshot, Remote Mirroring included at No Charge

Ease of use Management Graphical User Interface (GUI)

March 2012SSDs for Gen3

R11.1Gen2 – Gen3

mirroringGUI 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 cost Drive out cost

while while

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


while while

exceeding exceeding

existing existing

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

Inte

rconnect

iSCSI

Host

Data

Modules

Interface

Modules

SSD

SSD

XIV System Components


XIV Module

UPSUPS UPS

XIV Module

Inte

rconnect

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 managementRAID 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%) o r 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 but � Hot-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 1Auto 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

VolumePointer Map

Data Chunks

XIV Snapshots: Powerful and Efficient Local Replication


Data Module 4Data Module 3


Snapshot

Pointer MapSnapshot

Pointer MapSnapshot

Pointer MapSnapshot

Pointer MapIB

VolumePointer 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 MapSnapshot

Pointer Map

Snapshot

Pointer Map

Data Module 2

Data Module 3

Data Module 1


Snapshot

Pointer MapSnapshot

Pointer MapIB

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

ApplicationData

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

� High performance, near


Storage Manager 6

With OptionalTSM BackupIntegration

�SVC�XIV

�DS8000�Storwize

V7000�DS 3/4/5*

For IBM and non-IBM Storage

� High performance, near instant restore capability

� Integrated with IBM Storage Hardware

� Simplified deployment

� High performance, near 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 withouthost 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 101317 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

5151

51v

5151

5151

5151

17 17

1717

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


35

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 2Site 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

/oracleDisk 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_1vo

lASM_1

vol_12

8KASM_1

vol_1M

ASM_1vo

l_8MASM_2

vol_8M

ASM_6vo

l_8MASM_1

vol_64

MASM_2

vol_64

M

Tim

eData 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/Storage_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 reportingpackages 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

Gen2Ethernet 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


Gen3InfiniBand Interconnect


UPS units

Data Modules

Interface ModulesiSCSI ports with 6 modules: 0

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 Gen32810/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 Memory120 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

ProcessorE5410 Intel Quad Core

XEON 2.33 GHzE5620 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 ConfigurationTotal number of modules(Configuration type)

6partial

9partial

10partial

11partial

12partial

13partial

14partial

15full

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,000XIV

60,000XIV Gen3

55,000XIV

115,000XIV 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,000XIV

66,000XIV Gen3

3,034XIV

10,300XIV Gen3

42,000XIV

125,000XIV Gen3 1,542

XIV6,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)



� Client can use the on-demand capacity whenever they want

� Agrees to purchase full system capacity within 12 months


� 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 Toolhttps://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

4 CoD Activations --> 37133


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

Technology

ibm acquisitiondec

global ibm integration

ibm portfoliowinning

ibm white spacebroad

storage system6

virtualized storage

pb usable

new clients