IBM® Edge2013 - Storage Migration Methods

© 2013 IBM Corporation

Storage Migration Methods Session 1090

Chuck Laing- Senior Technical Staff Member (STSM)

14 June 2013


My objective is simple

To teach someone here today:

– One new concept that will make you better

– Even better, if many of you learn a few new things today that will make your job

easier

2 2

© 2013 IBM Corporation 3

Addressing data migration issues

How do I address and avoid:

– Extended or unexpected downtime

– Data corruption

– Missing data or data loss

– Application performance issues

– Technical compatibility issues


4

Knowledge is POWER!

As System’s Administrators – we don’t always KNOW what we

don’t know about storage – Ask for storage, leveraging what you know

– Avoid bottlenecks

– Use tools available

– Speed problem isolation

– Make more informed architectural decisions

As Storage Administrators – we don’t always KNOW how the

storage will be utilized – Make more informed architectural decisions

– Ask what is needed for best performance and IO separation

What we are NOT going to do today: – Try to turn Sys Admins into Storage Admins or vice versa

– Boil the ocean 4


Problem statement

Storage and System Administrators often clash in the common goal to

achieve data performance and availability, leading to:

– Too many logical configuration related outages

– Performance related enhancements not working to specification

– Leading causes:

• Lack of understanding configurations

• No cohesiveness between the logical and physical implementations

• Lack of communication between System and Storage Administrators

Resulting in:

– A lack of data reliability and IO throughput

5 5


The top ten things to know

Systems Administrators should

know about Storage

What should I be aware of/what should I

avoid? (Tips & Pitfalls-Tuning)

Storage Overview - what's inside?

– What is the Physical makeup?

– What is the Virtual makeup (good

throughput design tips)?

– What is a Storage Pool ?

– Where do I place data?

Connectivity- Picking the right drivers

Host Attachment Kits

How to Improve Performance using LVM

Documentation - why it matters

Topology Diagrams

Disk Mapping (view at a glance)

Easy Storage Inquiry Tools

Bottlenecks

Storage Admins should know

about Logical Volume Manager

(LVM)

What should I be aware of/what should I

avoid? (Tips & Pitfalls-Tuning)

Hdisk Volume (LUN) purpose ?

– DB type

– Access Patterns

– Number of spindles required

– Stripe

– Spread

– Mirror

What is a Volume Group (VG)?

What I a Logical Volume (LV)?

Disk Mapping (view at a glance)

Easy Storage Inquiry Tools

Bottlenecks

………………………

………………………..

6


Physical to logical makeup

7 7

A deeper dive


Storage Subsystems

SVC Provides Flexibility Across Entire Storage Infrastructure

SAN

HDS DS8000

Volume

SAN Volume Controller

DS4000 HP EMC

Combine the

capacity from

multiple arrays on

frames into storage

pools

Advanced Copy Services

Apply copy

services across

the storage pool

Manage the

storage pool from

a central point

Make changes to

the storage without

disrupting host

applications

Volume Volume Volume

SATA 15K

rpm RAID 5 JBOD RAID 1

What is SVC?

NO…Saying SAN Volume Controller doesn't count!

8


Volume

Storage

Pool Stripe

16MB – 2GB

Managed

Disk

LUN

mdisk0

100GB

mdisk1

100GB

mdisk2

100GB

mdisk3

100GB

mdisk6

200GB

mdisk5

200GB

mdisk4

200GB

EMC

100GB

EMC

100GB

EMC

100GB

EMC

100GB

IBM

200GB

IBM

200GB

IBM

200GB

mdiskgrp0 [EMC Group]

400GB

mdiskgrp1 [IBM Group]

600GB

vdisk0

125GB

vdisk2

525GB

vdisk3

1500GB

vdisk4

275GB

vdisk5

5GB

Mapping to Hosts w/SDD or supported MultiPath Driver

SVC - From Physical to Logical View

vdisk1

10GB

Space-efficient


vdisk3

10

Examples of correct Host to SVC Cluster zoning

vdisk1

vdisk2

Preferred path for vdisk1 is SVC

N1P2 & N1P3

Non Preferred path for vdisk1 is

SVC N2P2 &N2P3

Preferred path for vdisk2 is SVC

N2P2 & N2P3

Non Preferred path for vdisk2 is

SVC N1P2 &N1P3

vdisk1

vdisk2 vdisk3 vdisk4

vdisk4


DS8000 Hardware Physical Makeup

Summary - DS8700 (2-way/4 way base frame)

242x model 941

Familiar Layout 99,999% = ¼ day in 72 years MTBF

Is it important to know the physical makeup?; Does it really matter?

11


12

Physical to Logical - peeling back the layers

Arrays

across

Enclosures A B

Even numbered extpools Primary IO Data flow ownership

Balance

Odd numbered extpools Primary IO Data flow ownership

Just like an onion --

virtualization has many layers


How does the DS8000 virtual layer work?

Raid-0 only

13


DS8000 Virtualization layers (Concepts & Architecture)

How logical extents in ranks are formed from the DS8000, 6+P+S type array format

EXT 1 EXT 3 EXT 3 EXT 4 EXT 5 EXT 2 EXT 3 EXT 4 EXT 5 EXT 1

1GB

EXT 2

1GB EXT 3

1GB EXT 4

1GB

EXT 5

1GB


Since the time to complete an I/O operation depends on:

EXT 1 EXT 3 EXT 3 EXT 4 EXT 5 EXT 2 EXT 3 EXT 4 EXT 5 LV 1 LV 2 LV3 LV4 LV5

LUN 1

LUN 3

LUN 1 Made up of strips from the outer section/edge of each physical Disk RAID-5 6+P

LUN 3 Made up of strips from the middle sections of each physical Disk RAID-5 6+P

What causes disk latency?

Does Cache mitigate disk latency?

a. Seek time- time to position the read/write head

b. Rotational delay- time waiting for disk to spin to proper starting point

c. Transfer time

You could deduce that: a) Logical-disk3 would be a better place to store data that will be randomly accessed since the read/write heads would

most likely have shorter seek times to the middle of the disks.

b) Logical-disk1 would provide greater sequential throughput since it is on the outer edge of the disks.


LUN Sharing Best practices … is it OK?

You should know!

LUNs sharing the same array/rank in one extpool


IBM XIV Storage Distribution Algorithm

Each volume is spread across all drives

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

XIV algorithm automatically distributes partitions across all disks in the system

pseudo-randomly

Data Module

Interface

Data Module

Interface

Data Module

Interface

Switching

17


Node 4

XIV Distribution Algorithm on System Changes

Data distribution only changes when the system changes

– Equilibrium is kept when new hardware is added

– Equilibrium is kept when old hardware is removed

– Equilibrium is kept after a hardware failure

Data Module 2

Data Module 3

Data Module 1

[ hardware upgrade ]

Data Module 4


XIV Distribution Algorithm on System Changes

Data distribution only changes when the system changes

– Equilibrium is kept when new hardware is added

– Equilibrium is kept when old hardware is removed

– Equilibrium is kept after a hardware failure

Data Module 2

Data Module 3 Data Module 4

Data Module 1

[ hardware failure ]

The fact that distribution is full and

automatic ensures that all spindles join

the effort of data re-distribution after

configuration change.

Tremendous performance gains are seen

in recovery/optimization times thanks

to this fact.


Tips – What are the most common/Important OS I/O Tuning Parameters?

Device Queue Depth

– Queue Depth can help or hurt performance per LUN

• Be aware of Queue Depth when planning system layout, adjust only if necessary

• To calculate - best thing to do is go to each device “Information Center” URLs listed in

link slide

• What are the default Queue Depths? ___

HBA transfer rates

– FC adapters

LVM striping vs spreading

Data Placement

– Random versus sequential

– Spreading versus Isolation

• Queue Depth is central to the following fundamental performance formula:

• IO Rate = Number of Commands * Response Time per Command

• For example:

– IO Rate = 32 Commands per Second / .01 Seconds (10 milliseconds) per Command = 3200 IOPs

Some real-world examples:

• OS=Default Queue Depth= Expected IO Rate

• AIX Standalone = 16 per LUN = 1600 IOPs per LUN

• AIX VIOS = 20 per LUN = 2000 IOPs per LUN

• AIX VIOC = 3 per LUN = 300 IOPs per LUN

• Windows = 32 per Disk = 3200 IOPS per LUN

20

Source: Queue Depth content provided by Mark Chitti


Data Placement and Host Vdisk mapping

Spreading versus Isolation

–Spreading the I/O across MDGs exploits the aggregate throughput offered by more physical resources working together

–Spreading I/O across the hardware resources will also render more throughput than isolating the I/O to only a subset of hardware resource

–You may reason that the more hardware resources you can spread across, the better the throughput

• Don’t spread file systems across multiple frames

Makes it more difficult to manage code upgrades, etc.

Should you ever isolate data to specific hardware resources? Name a circumstance!

Slide Provided by Dan Braden

• Isolation

– In some cases more isolation on dedicated resources may produce better I/O throughput by eliminating I/O contention

– Separate FlashCopy – Source and Target LUNs – on isolated spindles

21


Data Placement – What causes THRASHING?___

Most commonly when workloads peak at the same time or log files and data files share physical spindles

Strip2

Strip4

Strip5

Strip1

Strip3

LUN1 made of strips on the outer edge of the DDMs (1s) also could have App A Raid-5 7+P

LUN3 made of strips in the middle of the DDMs (3s) also could have App B Raid-5 7+P

Placing Applications on the same LUNs/Pools result in IO contention

Extent pool or 8 Ranks

4

2 5

3

1

4

2 5

3

1

4

2 5

3

1

4

2 5

3

1

4

2 5

3

1

4

2 5

3

1

4

2 5

3

1

4

2 5

3

1

For existing applications, use storage and server performance monitoring tools to understand current

application workload characteristics such as:

• Read/Write ratio

• Random/sequential ratio

• Average transfer size (blocksize)

• Peak workload (I/Os per second for random access, and MB per second for sequential access)

• Peak workload periods (time of day, time of month)

• Copy services requirements (Point-in-Time Copy, Remote Mirroring)

• Host connection utilization and throughput (HBA Host connections)

• Remote mirroring link utilization and throughput

22


Data Placement - Storage Pools and Striping

• Sequential Pools

• Striped Pools

– Should you ever stripe with previrtualized volumes?

– We recommend not striping or spreading in SVC, V7000 and XIV Storage Pools

– Avoid LVM spreading with any striped storage pool

– You can use file system striping with DS8000 storage pools

• Across storage pools with a finer granularity stripe

• Within DS8000 storage pools but on separate spindles when volumes are created sequentially

Host Stripe - Raid-0 only

Host Stripe

No Host Stripe

Host Stripe

S

t

r

i

p

e

23


RAID array

LUN or logical disk

1

2

3

4

5

1

PV

2 3 4 5

datavg

# mklv lv1 –e x hdisk1 hdisk2 … hdisk5

# mklv lv2 –e x hdisk3 hdisk1 …. hdisk4

…..

Use a random order for the hdisks for each LV

Disk subsystem


Random IO Data layout

What does random LV creation order, help prevent

____?

24

Source: Slide provided by Dan Braden


Sequential IO Data layout

Does understanding the backend enable good front-end configuration?

Sequential IO (with no random IOs) best practice:

–Create RAID arrays with data stripes a power of 2

• RAID 5 arrays of 5 or 9 disks

• RAID 10 arrays of 2, 4, 8, or 16 disks

–Create VGs with one LUN per array

–Create LVs that are spread across all PVs in the VG using a PP or LV strip

size >= a full stripe on the RAID array

–Do application IOs equal to, or a multiple of, a full stripe on the RAID array

–Avoid LV Striping

• Reason: Can’t dynamically change the stripe width for LV striping

–Use PP Striping

• Reason: Can dynamically change the stripe width for PP striping


25


Data Layout - OS Spreading versus Striping

•Is there is a difference? What’s the diff?

– Do you know what your volumes are made of?

– Change Vpath to hdisk here.

File system spread

26

Source: Redbook SG24-6422-00 IBM 800 Performance Monitoring and Tuning Guide


Data Layout Summary

• Does data layout affect IO performance more than any tunable IO parameter?

• Good data layout avoids dealing with disk hot spots

– An ongoing management issue and cost

• Data layout must be planned in advance

– Changes are generally painful

• iostat might and filemon can show unbalanced IO

• Best practice: evenly balance IOs across all physical disks unless TIERING

• Random IO best practice:

– Spread IOs evenly across all physical disks unless dedicated resources are needed to

isolate specific performance sensitive data

• For disk subsystems

– Create RAID arrays of equal size and type

– Create VGs with one LUN from every array

– Spread all LVs across all PVs in the VG

27


Track data placement and Host Vdisk mapping Disk mapping at a glance

–Mapping becomes important

Spreading versus isolation

• Isolation • Spreading

Documentation – Does it matter? Why?

28


Documentation – Why it matters

How do I achieve SVC node to Server Balance?

• Use the SVCQTOOL listed under the tools section of this slide

deck to produce a spread sheet similar to this Or

• Use the script found in the speaker notes of this slide

• Add a column for preferred node to host client

29

Spread sheet developed by Keith Williams


Are there any automated storage inquiry tools out there that will help me understand my setup?

Storage tools

– Gathers information such as, but not limited to:

• LUN layout

• LUN to Host mapping

• Storage Pool maps

• Fabric connectivity

– DS8QTOOL

• Go to the following Website to download the tool:

http://congsa.ibm.com/~dlutz/public/ds8qtool/index.htm

– SVCQTOOL

• Go to the following Website to download the tool:

http://congsa.ibm.com/~dlutz/public/svcqtool/index.htm

30





SA - How do I improve disk performance on the Host?

• Reduce the number of IOs

– Bigger caches

• Application, file system, disk subsystem

– Use caches more efficiently

– No file system logging

– No access time updates

• Improve average IO service times

– Better data layout

– Reduce locking for IOs

– Buffer/queue tuning

– Use SSDs or RAM disk

– Faster disks/interfaces, more disks

– Short stroke the disks and use the outer edge

– Smooth the IOs out over time

• Reduce the overhead to handle IOs

31


Troubleshooting – What’s the most common thing that changes over time?

Rank

Rank

Rank

Rank

Pool 1

Vdisk1

Vdisk2

App A

App B

Host A

Host B

An ounce of prevention is worth a pound of cure

Data Migration

Rank

Rank

Rank

Rank

Pool 2

Map

Map

Apps sharing the same physical spindles on traditional arrays

may peak at the same time

• Depending on the work load characteristics, isolating the workload may prove to be more

beneficial and out perform a larger array.

– There are 3 important principles for creating a logical configuration for the Storage Pools to optimize

performance:

• Workload isolation

• Workload resource-sharing

• Workload spreading

Some examples of I/O workloads or files/datasets which may have heavy and continuous I/O access patterns are:

• Sequential workloads (especially those with large blocksize transfers)

• Log files or datasets

• Sort/work datasets or files

• Business Intelligence and Data Mining

• Disk copies (including Point in Time Copy background copies, remote mirroring target volumes, and tape simulation

on disk)

• Video/imaging applications

• Engineering/scientific applications

• Certain batch workloads

• I always separate Log files from Data files for best performance.

32

http://www.mediapool.dewe.de/public/ibm/shop/archive/pic_show.php?path=/opt/coma/archive/ibm/data/7/thumb/1056986_4.jpg&file=1056986&id=1015648&show_doss=yes&title=IBM eServer xSeries 230 (2000)

http://www.mediapool.dewe.de/public/ibm/shop/archive/pic_show.php?path=/opt/coma/archive/ibm/data/7/thumb/1056986_4.jpg&file=1056986&id=1015648&show_doss=yes&title=IBM eServer xSeries 230 (2000)


StorAdmin – How do I improve disk performance?

• Data layout affects IO performance more than any tunable IO parameter

• If a bottleneck is discovered, then some of the things you need to do are:

– Identify the hardware resources the heavy hitting volumes are on

• Identify which D/A pair the rank resides on

• Identify which I/O enclosure the D/A pair resides on

• Identify which host adapters the heavy hitting volumes are using

• Identify which host server the problem volumes reside on

• Identify empty non used volumes on other ranks – storage pools

– Move data off the saturated I/O enclosures to empty volumes residing on less used

ranks/storage pools

– Move data off the heavy hitting volumes to empty volumes residing on less used hardware

resources and perhaps to the another Storage Device

– Balance LUN mapping across

• Backend and host HBAs

• SVC IOgrps

• SVC preferred nodes

– Change Raid type.

33


Troubleshooting: What are some Storage Bottlenecks?

• After verifying that the disk subsystem is causing a system bottleneck, a number of solutions

are possible. These solutions include the following:

• Consider using faster disks SDD will out perform HDD, etc.

• Eventually change the RAID implementation if this is relevant to the server’s I/O workload

characteristics.

– For example, going to RAID-10 if the activity is heavy random writes may show

observable gains.

• Add more arrays/ranks to the Storage pool.

– This will allow you to spread the data across more physical disks and thus improve

performance for both reads and writes.

• Add more RAM

– Adding memory will increase system memory disk cache, which in effect improves disk

response times.

• Finally, if the previous actions do not provide the desired application performance:

– Off-load/migrate - processing to another host system in the network (either users,

applications, or services).

34


35 35

Summary

Knowing - what's inside will help you make informed decisions?

You should make a list of the things you don’t know

– Talk to the Storage Administrator or those who do know

A better Admin understands 1. The backend physical makeup

2. The backend virtual makeup

3. What's in a Storage Pool for better data placement

4. Avoid the Pitfalls associated with IO Tuning

5. Know where to go to get right device drivers

6. Know why documentation matters

– 7. Keep Topology Diagrams

– 8. keep Disk Mapping documentation

– 9. Be able to use Storage Inquiry Tools to find answers

– 10. Understand how to troubleshoot storage performance bottlenecks

35


Plan

Execute

Validate

Evaluate

A four step Migration Process

Migration Process

36


Evaluate Storage Migration Methods


Evaluate the data migration process

Migrating data is always a disruptive process. Whatever the migration

technique used, it always affects to some degree the normal operations of

the system.

– Selecting the appropriate technique depends on:

• The criticality of the data being moved

• The resources available

• Other business constraints and requirements.

Note: Risks should be identified depending on the migration technique used. We strongly

recommend that you consider selecting the technique that is the best compromise between

efficiency and the least impact to the system users.


Evaluate the migration technique summary

Make a list of Pros and cons (each offering strengths and limitations)

Migration technique Pros Cons

– Host-based – LVM

– LDM

– Add-on software such as VxVM

– Volume (block) level

– TDMF

– Generally lowest initial implementation cost

– Leverages existing and IP network

– LVM or LDM tools available

– Storage device-agnostic

– Leverages existing Operating System skills

– Migration can happen on-line during peak

hours

– Consumes host resources

– Operating system specific

– Management can become complex and time

consuming

– Each host is its own island – no central

management console

– May cause an initial outage to install the utility

or software if it is not already existing on the

host

– Network-based – Fabric

TDMF-IP

– Supports heterogeneous environments – servers

and storage

– Single point of management for replication services

– Higher initial cost due to hardware & replication

software

– Requires proprietary hardware and may require

implementation of Storage

– Application-based – SVC

– Migration can happen on-line during peak hours

– Supports heterogeneous environments – servers

and storage

– Single point of management for migration

– Requires an initial outage to bring the host

volumes on-line to SVC

– Requires the host to reboot to load or upgrade

the multipathing drivers

– Tape backup/restore

based – TSM

– Etc

– Does not require additional special tools, software

or hardware

– Does not require additional skills or training

– Requires the disruption of the applications and

down time

– Slow and cumbersome


Evaluating key decision factors

Key Factors Description Capability

– Performance How quickly can data be copied from the

source to the target, balanced against system

overhead

– TDMF

– SVC

– Primary volume/

Source data

protection

If something goes wrong, the migration can be

terminated and application processing

restarted or continued on the source

data/device

– TDMF

– SVC with limitations

– LVM / LDM

– Tape based

– Implement tiered

storage

Moving data to a different array or to different

storage media for cost performance without

disruption

– TDMF

– SVC

– LVM / LDM

– Multi-vendor

environments

Many data centers use hardware from several

vendors, which can result in source and target

hardware being from different vendors

– TDMF

– SVC

– LVM / LDM with

possible restrictions

– Fabric

– Tape based

– Application downtime Applications have different levels of business

criticality and therefore have varying degrees

of acceptable downtime

– All with limits

– TDMF

– SVC

– LVM / LDM

– Fabric


Evaluating migration triggers

Disk consolidation can trigger data

migration of storage when:

You want to change computer systems

You need to upgrade to new products to

stay competitive

New functions of evolving technology

are introduced

Database growth

You need newer, faster, higher density

devices

Taking advantage of the ever improving

price to performance ratio of new

storage devices

You just require more flexibility

You need to relocate you data center

You need to reduce the foot print of your

storage subsystem within the data

center

Leveraging data migration to provide

Disaster Recovery solutions

Storage migration can trigger LVM

data movement when:

You want to spread IO evenly across all

the disks in the VG

You need to align IO access patterns

– Random access

– Sequential access

You want to protect the data integrity

Database growth

Database refreshes

You need consolidate the space in a VG

or multiple VGs

You need to troubleshoot an ailing

volume for

– Performance

– Availability (failure boundary)

– You need to separate data into

separate LVs

41


A few LVM migration do’s and don’ts

Do

Consider failure boundaries

Span multiple frames for temporary

migration purposes

Add LUNs to the VGs spanning multiple

frames temporarily

Put sequential accessed LVs on their

own LUN

Take advantage of the disk subsystems

Treat Raid array groups as single disks

Use PP Striping

– Reason: Can dynamically change

the stripe width for PP striping

……………

Don’t

Span multiple storage frames in one LV

Avoid LV Striping

– Reason: Can’t dynamically change

the stripe width for LV striping

Avoid pladding

– Striping on Striping

Using the same spindles for data and

logs

………….

42


Plan Storage Migration Methods


Planning phase

A successful data migration always requires substantial

evaluation and planning

Adequate planning is the critical success factor in a migration

project

Develop a high level migration plan

Develop a detailed migration plan


Plan data migration techniques in Open Systems

– This functionality can be used for:

• Redistribution of LV’s and their workload within or across back-end storage

• Moving workload onto newly installed storage subsystems

• Moving workload off of storage so that old/failing storage subsystems can be

decommissioned.

• Moving workload to re-balance a changed workload

• Migrating data from legacy back-end storage to newer managed storage.


Plan

Determine whether you can migrate data online or off-line

Online migrations means data can be moved from Source to Target Platforms with:

– No impact to the end user outside of unscheduled outage windows

– No data I/O loss between the application and the disk storage subsystem

– Very little performance impact affecting the end user

Off-line migrations means when data is moved:

– Data must be in a known state, typically requiring updates or changes to cease while the

movement occurs.

– Data could be unavailable for an extended periods of time, perhaps several hours or

days.


Planning phase - Example migration methodology plan Action Item Assigned Status Date

– Establish a migration management team

– Gather availability and production schedules

– Document Change Control procedures and

incorporate into the plan

– Document the time line for migration activities

– Announce the migration at least 30 days prior to

the intended target migration date

– Gather information about the storage server

environment and applications (lists, commands,

scripts and/or drawings)

– Schedule a pre-migration rehearsal that includes all

the members on the migration team and a data

sampling that will enable the application groups to

appropriately conduct the pre- and post migration

verification process

– Establish a “Migration Status” call-in process

– Utilize a “Migration Planning Checklist” to assure

that all of the pre migration planning steps have

been executed


Establish a migration management team technical migration team

Team members may include but are not limited to:

– Project manager

– Client (account) manager

– DBA/Application owners

– System administrator

– Network administrator

– Security administrator

– Firewall administrator

– Disk storage administrator

– Backup/Recovery administrator

– SAN fabric administrator

– Hardware CE

– Floor planner

– Cable vendor

– Disaster/Recover administrator

– IT Architect


Gather availability and production schedules

Some examples of application availability may be but are not limited to the

following list:

– Month/end /quarterly processes

– FlashCopy® or Metro/Global mirror/copy running processes and their time restrictions.

– Database/application refreshes


Planning Phase - Example drawings may look like this:

For example you may want to go from an Hitachi 9980 on the left to a DS8000/SVC on the

right

Preparation of physical/zoning cabling setup from the backend through the SAN fabric to the

hosts and SVC

SANSAN

Brocade 1 Brocade 2

Current

Layout

CHA P

A B C D E F G H

1P 1Q

CHA P

J K L M N P Q R

2X 2Y

CHA P

A B C D E F G H

2V 2W

CHA P

J K L M N P Q R

1R 1S

Right Controller(2)Left Controller(1)

8

Port

35 06426219 2138

fcs3

3v-0810000000C92D1A97

Host Server AIX hrinprd

fcs2

3p-0810000000C93830A5

fcs0

5V-0810000000C93D6ADA

fcs1

5b-0810000000C93D72C3

Port

50060E80039C6212

50060E80039C6218

50060E80039C6202

50060E80039C62088535248 474628

46

Frame 1

SVCNode 1

HBA 1

P1 P2 P3 P4

HBA 2

Node 4

HBA 1

P1 P2 P3 P4

HBA 2

Node 3

HBA 1

P1 P2 P3 P4

HBA 2

Node 2

HBA 1

P1 P2 P3 P4

HBA 2

Even SAN Fabric 13 14 15 1609 10 11 12

05 06 07 0801 02 03 04

ODD SAN Fabric 13 14 15 1609 10 11 12

05 06 07 0801 02 03 04

CHA P

A B C D E F G H

1P 1Q

CHA P

J K L M N P Q R

2X 2Y

CHA P

A B C D E F G H

2V 2W

CHA P

J K L M N P Q R

1R 1S

Right Controller(2)Left Controller(1)


Planning phase – design requirements

Action

Item

Application Environment

Databases to be moved (DB2, Informix®, Oracle®, SQL, Sybase)

Database version

Database size

Availability requirements of databases (any existing SLA’s, downtime issues

to consider)

Cluster environment (MSCS, Veritas, Sun, HACMP™, MC/Service Guard,

etc.)

Understanding the requirements may help simplify migration process

Action

Item

Network Environment (if applicable)

Topology

Speed of network


Action

Item

Storage Environment

Storage Vendor and model (EMC, HDS, IBM, STK, Dell, HP)

Channel type (ESCON, FICON, Fibre, iSCSI, SAN)

SAN HBA & Model (Qlogic, Emulex, JNI)

Number of Channel Paths

Logical to Physical mapping (i.e. RAID-1 vs. RAID-5)

Number of Source volumes to be migrated

Volume sizes

Identify Target volumes to receive source data

Understanding the requirements may help simplify migration process

Planning phase – design requirements


Planning summary - Example migration methodology approach

Action

Item

Migration and validation methodology checklist

Based on the information gathered in the planning phase, structure the

migration architecture to match the production requirements

Use checklists to ensure any operating patches and software are at the

correct levels

Build detailed migration procedures following the chosen architecture

Put together a schedule of events with time lines to implement the migration

procedures

Establish an initial test plan to validate the initial installation of all required

components

Develop a cooperative deployment plan

Write and configure any automation scripts that will speed up the process

Run a simple initial test plan that validates the migration process

Implement the migration procedures and time line built in the design phase

Verify the migration completion by checking the successful completion and

status of the migration jobs

Utilize a “Migration Planning Checklist” to assure that all of the pre migration planning steps

have been executed.


Execute Storage Migration Methods


Execute

During the migration phase, you will need to:

– Communicate your plans

– Obtain, install and configure any necessary:

• Hardware

• Software

• Automation scripts and tools (to perform the actual data migration)


Execute

An example migration may go as follows:

–This high level illustration is the execution migratepv –l


Execute summary - Example migration methodology approach

Source: If applicable, describe source origin

LVM using migratepv

Command Process and explanation

lsvpcfg Identify and assign the DS8000 LUNs to the targeted AIX host server

“ “ Identify the ESS source and DS8000 targeted LUNs on the host server

bootinfo -s Identify the sizes of the DS8000 target LUNs

extendvg Move the DS8000 LUNs into the VGs appropriately

lsvg-p Verify the DS8000 LUNs are added to the VG

lsvg -l Identify the logical volumes (LVs) to migrate

migratepv -l

lv_name

Copy LV data from the ESS source LUNs to the DS8000 target LUNs

lsvg -p

vg_name

Verify the LUNs are copied

rmdev -dl Remove the ESS source LUNs from the VGs

rmdev -dl Delete the device definitions from the host ODM

Lsdev –Cc disk Verify the device definitions are are removed

In the ESS, unassign the LUNs from the host server


Execute summary - Example migration methodology approach LVM using mklvcopy

Command What is does

lsvpcfg Identify and assign the DS8000 LUNs to the targeted AIX host server

chvolgrp –dev Identify the ESS source and DS8000 targeted LUNs on the host server

bootinfo -s Identify the sizes of the DS8000 target LUNs

extendvg Move the DS8000 LUNs into the VGs appropriately

lsvg -l Verify the DS8000 LUNs are added to the VG

lsvg -p Identify the logical volumes (LVs) to migrate

lslv -l lv_name Determine how the LVs are spread across the vpaths

mklv -y

lvdummy

Reserve free space on each LUN for an even spread of the data across LUNs

mklvcopy Copy LV data from the ESS source LUNs to the DS8000 target LUNs

lslv-l Verify the lv copies are made

syncvg Syncronize the LV data from the ESS source LUNs to the DS8000 target

LUNs

lsvg -l Verify that the sync isn't showing stale, it should show as sync’d


Command What these commands do

lslv -l Verify the source and target LUNs for each lv

rmlvcopy Remove the source copy of the lv from the ESS LUNs

lsvg -p Verify that all the source ESS LUNs are free with no data

reducevg Remove the ESS source LUNs from the VGs and verify the removal

rmdev -dl

hdisk#

Delete the device definitions from the host ODM

lsdev -Cc

disk

Verify the device definitions are are removed

In the ESS, unassign the LUNs from the host server

LVM using mklvcopy (continued) Execute summary - Example migration methodology approach


Validate Storage Migration Methods


Validate

It is important to validate that you have the same data and functionality of

the application after the migration

You should make sure that the application runs with the new LUNs, that

performance is still adequate, that operations and scripts work with the

new system


A sample validation list may include but not be limited to the following items:

Compile migration statistics

Prepare a report to highlight:

–What worked

–What didn’t work

–Lessons learned

• Share the report with all members of the migration team

• These types of reports are critical in building a repeatable and consistent process

through continuous process improvement, building on what worked and fixing or

changing what didn’t work. Further, documenting the migration process can help you

train your staff, and simplify or streamline the next migration you do, reducing both

expense and risk


Overall Summary Storage Migration Methods


Migration Methodology Summary

Validate Plan Plan Execute

– Analyze business

impact

– Risks

– Business

interviews

– Criticality of data

being moved

– Performance

– Migration types

– Key factors

– Multi-vendor

environment

requirements

– Application down

time

– Determine

migration

requirements

– Identify existing

environment

– Define future

environment

– Create migration

plan

– Develop design

requirements

– Migration types

– Create migration

architecture

– Develop test plan

– Obtain software

tools and licenses

– Communicate

deployment plan

– Validate HW & SW

requirements

– Customize

Migration

procedures

– Install & configure

– Run pre-validation

test

– Perform migration

– Verify migration

completion

– Run Post validation

test

– Perform knowledge

transfer

– Communicate

Project information

– Create report on

migration statistics

– Conduct migration

close out meeting


Thank you!

For you interest

and attendance


Questions and Answers

Storage Migration Methods


Backup slides and extra reference materials provided separately

Storage Migration Methods

Documents

IBM® Edge2013 - Storage Migration Methods