s vc based migration

8/13/2019 s Vc Based Migration

http://slidepdf.com/reader/full/s-vc-based-migration 1/28

SVC based storage migration

A paper by Gauurav Sabharwal

System and Technology Group Storage Lab Services India Software Lab, IBM



Implementation of LBGM on IBM Storwize V7000& Performance Monitoring

© Copyright IBM Corporation, 2012

Table of contents

1. Introduction and Acknowledgements..................................................................... 1

1.1. IBM System Storage SAN Volume Controller overview ....................................................... 2

1.2. Data Migration approach using Mirrored Volumes/Vdisks .................................................. 4

1.3. Understanding about Client environment ............................................................................... 5

1.3. Understanding about Target POC environment .................................................................... 6

1.4. Verify Interoperability ................................................................................................................. 7

2. XIV & SVC consideration as per best practices ................................................... 8

2.1. XIV Volume Creation considerations ....................................................................................... 9

2.2. SVC and XIV port definition consideration ........................................................................... 10

2.3. SVC extent size selection at Mdisk group level ................................................................... 11

2.4. Consideration on number of MDG at SVC ............................................................................ 13

3. Configuration of POC environment ........................................................................ 14

3.1. IBM XIV Connectivity and zoning with IBM SVC cluster ................................................... 14

3.2. IBM XIV Configuration .............................................................................................................. 14

3.3. IBM SVC Cluster configuration before migration ................................................................ 16

3.4. EMC VMAX Connectivity with IBM SVC Cluster ................................................................... 17

4. Migration activity ......................................................................................................... 18

4.1. Task need to performed at Host end ..................................................................................... 18

4.2. Task need to performed at EMC-Vmax management station .......................................... 18

4.3. Task need to performed at SVC end ..................................................................................... 19

4.4. Starting application at Host end ............................................................................................. 20

4.5. Starting the volume migration ................................................................................................ 21

Resources............................................................................................................................. 25

Trademarks and special notices .................................................................................. 26



SVC Based storage Migration© Copyright IBM Corporation, 2012

1. Introduction and Acknowledgements

This document is intended to help those who are migrating Volumes on

different Storage Systems using the IBM Total Storage SAN VolumeController. It is based on experiences gained by performing proof of concept

for one of the telecom company.

The purpose of the following sections is to help the reader to understand the

theoretical back-ground of SAN Volume controller capabilities for migration

activities and Virtualization consideration for each of the backend storage.

Our storage environment consisted of an EMC Symmetrix 8730, EMC VMAX

and IBM SAN Volume Controller and an IBM XIV.

We outline experience from migrating data volumes in heterogeneous host

environment. The host environment used consisted of a HP-UX 11 and a

Solaris 9.

The reader should have a good working knowledge of the mentioned Storage

Systems and the SAN Volume Controller.

Fabric Configuration is referred to only as what Server is zoned to what

Storage System.




1.1. IBM System Storage SAN Volume Controller overview

The IBM System Storage SAN Volume Controller is a scalable hardware and

software solution. It provides block aggregation and logical drivemanagement for different disk storage subsystems in a SAN environment.

SAN Volume Controller provides the following advantages:

A single view of the storage attached to the SAN: You can manage,

add, and migrate physical disks non-disruptively, even between storage

subsystems.

Storage virtualization: SAN Volume Controller creates a storage pool ofmanaged disks from attached disk storage subsystems. These managed

disks are then mapped to a set of volumes for use by host computer

systems.

Scalable: SAN Volume Controller can be used to manage all of your disk

storage requirements, or just a subset of them. SAN Volume Controller also

offers a large scalable cache using an algorithm.

Reduces the requirement for additional partitions: SAN Volume

Controller consumes only one storage partition for each storage server that

connects to it.

Improves access: SAN Volume Controller improves capacity utilization, and

spare capacity. Underlying physical disks can be reallocated non-disruptively

from an application server point of view irrespective of the server operating

system or platform type.

Simplifies device driver configuration on hosts: All hosts within your

network use the same IBM device driver to access all storage subsystems

through the SAN Volume Controller.

Supports split I/O group implementations: Split implementations are

not apparent to an application and are used across sites to cover application

high availability requirements. These implementations can be used in case of

high availability demands.




SAN Volume Controller is licensed according to the usable capacity that is

being managed. The advanced functions available on SAN Volume Controller,

such as FlashCopy, IBM Easy Tier®, Split I/O group, Mirrored volumes,

Metro Mirror, and Global Mirror are included.

The license cost is for the capacity of all storage managed by the SAN

Volume Controller,plus the capacity of the copy services maintained by the

SAN Volume Controller. You can upgrade at any time by purchasing a license

for the additional capacity required.

SAN Volume Controller supports a wide variety of disk storage and host

operating system platforms. For the latest information, see the following

web address

http://www-03.ibm.com/systems/storage/software/virtualization/svc/interop.html







1.2. Data Migration approach using Mirrored Volumes/Vdisks

Using volume mirroring creates two physical copies of a volume/Vdisk. Each

volume/Vdisk copy can belong to a separate storage pool/ Mdisk group, andeach copy has the same virtual capacity as the volume/Vdisk.

In the management GUI, an asterisk (*) indicates the primary copy of the

mirrored volume/Vdisk. The primary copy indicates the preferred volume for

read requests.

When a server writes to a mirrored volume/Vdisk, the system writes the

data to both copies. When a server reads a mirrored volume, the system

picks one of the copies to read. If one of the mirrored volume copies is

temporarily unavailable, the volume remains accessible to servers throughthe other copy. The system keep the track which areas of the volume are

written in the IOgrp bitmap space and resynchronizes these areas when both

copies are available.

You can create a volume with one or two copies, and you can convert a non-

mirrored volume into a mirrored volume by adding a copy. When a copy is

added in this way, the SAN Volume Controller clustered system synchronizes

the new copy so that it is the same as the existing volume. Servers can

access the volume during this synchronization process.

You can convert a mirrored volume into a non-mirrored volume by deleting

one copy or by splitting one copy to create a new non-mirrored volume. The

volume copy can be any type:

Image, striped, sequential, and either thin provisioned or fully allocated. The

two copies can be of different types.




1.3. Understanding about Client environment

Hardware Detail

HP Server HP-UX 11iv

Brocade -48000 SAN Switches FOS 6.3

EMC-VMAX 5874

EMC Vmax System

Storage

No. of Volumes are 256Each Volume size 68GB

Total Capacity= 17408 GB

HP-UX Host

EMC - VMAX

FabricAFabricB




1.3. Understanding about Target POC environment

Hardware Detail

HP Server HP-UX 11iv

Brocade -48000 SAN Switches FOS 6.3

EMC-VMAX 5874

IBM XIV A14 (15 Module) 10.04

IBM SVC Cluster (4 node) CF8 Version 6.2

FabricA

Fabric B

IBM XIV

EMC - VMAX

IBM SVC

HP-UX Host

SAN Layer




1.4. Verify Interoperability

The main objective of this POC was to study the present storage

environment and identify the scope of work for Data migration by using amethodology of Volume mirroring services of IBM SVC Cluster. It is also

required to assess the interoperability of the existing environment with IBM

SVC Cluster for the proposed migration.

As per present setup we are consider only one HP server environments for

POC activity.

Hardware Detail

Ia64 HP Server

RX 6600

HP UX -11 vi

Multipath driver Hp Native

EMC Vmax 5874

Brocade -48000 SAN

Switches

FOS 6.3

IBM SVC 6.2

IBM XIV 10.0.4

Verify the interoperatiblity at below provided link :-

http://www-03.ibm.com/systems/support/storage/ssic/interoperability.wss







2. XIV & SVC consideration as per best practices

Hardware Configuration

Hardware Module Capacity IOgrp

IBM XIV A14 15 79TB -

IBM SVC 4 Node Clsuter

(CF8 Model)

4 Node - 2

Brocade San Switch

48000

2 SAN Switches - -

2

1

4

3

Module9

IBM XIV Gen2

Storage System

2

1

4

3

Module8

21

43

Module7

2

1

4

3

Module6

2

1

4

3

Module5

2

1

4

3

Module4

1

2

34

(POC_SVC)

SVC I /O Group 0

(POC_SVC)

SVC I /O Group 11 2 3 4

1 2 3 4

1 2 3 4

1 2 3 4FabricA

Fabric B

Connectivity

Schematic




2.1. XIV Volume Creation considerations

IBM XIV System Gen2 A14 currently supports the following usable

capacities per system:

• 27TB to 79TB with 1TB drives (XIV Gen2 A14)

The minimum volume size is 17GB. While smaller LUNs can be created we

recommend large LUNs and they should be defined on 17GB boundaries to

maximize the physical space available.

• 17GB Gen2 A14 = 33554432 blocks

The important considerations for determining what size volume to create on

XIV and present to SVC are:

• Maximize available space and

• Number of volumes being created is divisible by the number of ports

on XIV zoned to SVC. This offers the best balance of the volumes across al

the ports.

For XIV Gen2 A14 systems utilizing 1TB drives, we recommend creating at

least 1632GB LUNs.

With a fully populated 15 module system, 48 LUNs are created. Each of the

12 ports on XIV A14 will have 4 LUNs presented to SVC.

Number of XIV ModulesInstalled

Number of LUNs(MDisks) at 1632GB

each

IBM XIV System TBused

IBM XIV System TBCapacity Available

6 16 26.1 27

9 26 42.4 43

10 30 48.9 50

11 33 53.9 54

12 37 60.4 61

13 40 65.3 66

14 44 71.8 73

15 48 78.3 79




2.2. SVC and XIV port definition consideration

SVC microcode supports a maximum of 16 WWPN ports from any WWNN in

case of IBM XIV one disk system have only one WWNN. The IBM XIV Systemsupports both iSCSI and Fibre Channel protocols but when connecting to

SVC, only Fibre Channel ports will be utilized.

The IBM XIV System supports from 8 to 24 FC ports, depending on the

configuration. We recommend using one 4Gb (XIV Gen 2 Model A14).

We recommends use 12 ports (WWPN) of IBM XIV for 15 module . As al

module have balance number of port zoned with IBM SVC . Select port

number 1 & 3 from each module of IBM XIV as they both belongs to diifrent

host channel.

Number of

IBM XIV

Modules

IBM XIV System

Modules with FC Ports

Number of

FC ports

available

on IBM

XIV

Ports Used

per Card

on IBM XIV

Number of

SVC ports

utilized

6 Module 4, 5 8 1 4

9 Module 4, 5, 7, 8 16 1 8

10 Module 4, 5, 7, 8 16 1 8

11 Module 4, 5, 7, 8, 9 20 1 10

12 Module 4, 5, 7, 8, 9 20 1 10

13 Module 4, 5, 6, 7, 8, 9 24 1 12

14 Module 4, 5, 6, 7, 8, 9 24 1 12

15 Module 4, 5, 6, 7, 8, 9 24 1 12




2.3. SVC extent size selection at Mdisk group level

SVC divides the managed disks (MDisks) that are presented by the IBM XIV

System into smaller chunks that are known as extents. These extents arethen concatenated to make virtual disks (VDisks). All extents that are used

in the creation of a particular VDisk must all come from the same Managed

Disk Group (MDG).

SVC supports extent sizes of 16, 32, 64, 128, 256, 512, 1024, 2048, and

8192 MB. The extent size is a property of the Managed Disk Group (MDG)

that is set when the MDG is created. All managed disks, which are contained

in the MDG, have the same extent size, so all virtual disks associated with

the MDG must also have the same extent size. The following diagram depicts

the relationship of an MDisk to MDG to a VDisk.

The following table shows the relationship between the extent size and the

maximum capacity of the cluster.

Extent Size Maximum Cluster Capacity

16 MB 64 TB

32 MB 128 TB

64 MB 256 TB

128 MB 512 TB

256 MB 1 PB

Extent 1a

Extent 1b

Extent 1c

Extent 1d

Extent 1e

Extent 1f

Extent 1g

Extent 2a

Extent 2b

Extent 2c

Extent 2d

Extent 2e

Extent 2f

Extent 2g

Extent 3a

Extent 3b

Extent 3c

Extent 3d

Extent 3e

Extent 3f

Extent 3g

Extent 1a

Extent 2a

Extent 3a

Extent 1b

Extent 2b

Extent 3b

Extent 1c

Extent 2c

Extent 3c

Create a stripedvirtual disk

A host VDisk is

a collection of

Extents

Managed Disk

MDisk1 MDisk2 MDisk3

VDisk1




512 MB 2 PB

1024 MB 4 PB

2048 MB 8 PB

8192 MB 32 PB

Extent Size to Maximum Capacity

The recommended extent size is 1GB to optimize capacity. While smaller

extent sizes can be used, this will limit the amount of capacity that can be

managed by the SVC Cluster. There is no expected performance benefit in

using smaller or larger extent sizes.

As the IBM XIV System configuration grows from 6 to 15 modules, use the

SVC rebalancing script to restripe VDisk extents to include new MDisks. The

script is located at www.ibm.com/alphaworks to the „all downloads‟ section

and search on „svctools‟.




2.4. Consideration on number of MDG at SVC

Volume shared from XIV to the SVC are represented or identify as Mdisks.

These all Mdisks can be part of single or multiple Mdisk groups.There arecertain consideration storage to storage

Do not include multiple disk subsystems in the same MDG, since the failure

of one disk subsystem will make the MDG go offline, and thereby all VDisks

belonging to the MDG will go offline.

If you are virtualizing multiple XIV systems (or other storage devices)

behind an SVC then you should create at least one managed disk group for

each additional storage device. With the exception of SSD based MDisks

used for Easy Tier, you should not have MDisks from different storagedevices in a common Managed Disk Group.

In general we recommend creating only one managed disk group for each

XIV as this is the simplest and most effective way to configure your storage.

If you have a large number of managed disk groups, you should be aware of

the way the SVC partitions cache when accepting write I/O (read I/O is not

affected). As the SVC can virtualize storage from a large number of storage

systems, you could potentially encounter an issue if there are slow draining

storage controllers. This occurs if write data is entering the SVC cache faster

than the SVC can de-stage write data to back-end disk. To avoid a write

cache full situation that would affect all storage devices that are being

virtualized, the SVC partitions cache for writes, on a managed disk group

level.

Number of MDGs equals # of partitions Maximum occupancy allowance as % of cache

1 100

2 75 3 40

4 30

5 or more 25




3. Configuration of POC environment

3.1. IBM XIV Connectivity and zoning with IBM SVC cluster

Connectivity:

a. ISLs should not be used for intracluster node communication or node

to storage controller.

b. Mixed port speeds are not permitted for intracluster communication.

All node ports within a cluster must be running at the same speed.

c. 12 ports ( port number 1&3/module) identified from XIV for SVC

connectivity

d. Connect port number 1 & 3 of each XIV module on Fabric A and Fabric

B respectively )

e. Zone all identified ports of IBM XIV with IBM SVC cluster nodes.

3.2. IBM XIV Configuration

a. Register SVC cluster at XCLI console with name “POC_SVC_Cluster1”

b. Define each node of SVC under Host cluster entity

“POC_SVC_Cluster1”

c. Define all IBM SVC node ports under each Node entity it relate to

Node1( define actual wwpn)







d. Define Storage pool at IBM XIV A14, Using complete capacity

e. Create Volume 48 Volume on XIV each of size 1632GB. It utilizes78336GB capacity of storage pool. Number of volume is multiple of

XIV host channel port zoned with XIV. So, each XIV port presenting a

4 Volumes of XIV to SVC cluster ( 48 Volumes, 12 ports consider to

zoned)




f. Mask all 48 Volumes of XIV to SVC cluster host entry. Using SCSI Lun

id 1 for first volume as SCSI Lun id 0 is reserved in IBM XIV.

3.3. IBM SVC Cluster configuration before migration

a. Configure each IO group bitmap setting for Vdisk mirroring.

b. Discover and identify new Mdisk assigned from XIV Storage at SVC

console.

c. Assigned appropriate name to all assigned volume from IBM XIV.




d. Assigned all new unmanaged 48 mdisks in to “XIV_mdg” mdiskgroup.

e. Verify the size of new mdisk group & quorum (if it‟s first mdg in SVC

cluster).

3.4. EMC VMAX Connectivity with IBM SVC Cluster

a. Identify the front-end port at EMC VMAX end to zone with IBM SVC

Cluster.

b. Zone all IBM SVC cluster ports with EMC VMAX front end port on both

Fabric A & Fabric B.

c. Verified the Zoning between SVC cluster & EMC VMAX is fine.

d. List all the devices assigned to the host from EMC Vmax.




4. Migration activity

4.1. Task need to performed at Host end

a. Identify the WWPN‟s of HP-UX server.

b. Define proper zoning between IBM SVC cluster & HP-UX server.

c. Stop the application at HP-UX server.

d. Unmount & export Volume group from the server.

4.2. Task need to performed at EMC-Vmax management station

a. Unmask all the devices assigned from EMC-VMAX to HP-UX server

b. Mask all devices was assigned to HP-UX server to now SVC except

VCMDB devices (to all the WWPN belongs to all nodes of SVC

cluster).

c. Refresh the EMC-VMAX database.




4.3. Task need to performed at SVC end

Using batch script (with the help of plink utility) for this migration

activity to perform all things faster & planned.

a. Detect all the volumes at SVC console assigned from EMC-VMAX to

SVC cluster.

b. Create two Mdisk group with required extent size (Extent size

doesn‟t matter for Vdisk migration & performance. It‟s only

considered for capacity management).

c. Converting all unmanaged mdisks (256 Volumes) to image mode

vdisk and assigned to two different pools (as mdisks limit is 128 per

pool) .

d. Register HP-UX server on both the IO group of SVC Cluster




e. Assign all these image mode volume to HP-UX server. Take care

about SCSI-id assignment on each IO-group.

4.4. Starting application at Host end

a. Identify the new devices at HP-UX server.

b. Import VG & mount all file systems.

c. Start the application at HP-UX server.




4.5. Starting the volume migration

All the Volumes assigned to HP-UX server still belongs to backend

EMC-VMAX storage.

a. Add vdisk copy on mdisk group belongs to backend storage IBM-XIV

for each volume.

Copy 0

IBM XIV Gen2

15 Modulestorage system

48 Numbers of LUNs fromIBM XIV single pool

Size of each LUN = 1632 GB

Total Capacity =78.3 TB

Identify all volumes as

"unmanaged" mdisks atIBM SVC level which are

assigned from EMCVmax

IBM SVC 4 node Cluster

EMC Vmax System

StorageNo. of Volumes are 256Each Volume size 68GBTotal Capacity= 17408

GB

HP-UX Host

Logical layout before migration

EMC - VMAX IBM XIV

Mdisk Group 0 Mdisk Group 1

1 2 3 4

1 2 3 4

1 2 3 4

Virtual Disk

Virtual Disk




b. Now Vdisk belongs to both mdisk groups ( EMC-Vmax & IBM

XIV) .

Copy 0 Copy 1

IBM XIV Gen2


48 Numbers of LUNs from

IBM XIV single pool

Size of each LUN = 16 32 GB


Identify all volumes as"unmanaged" mdisks atIBM SVC level which are

assigned from EMCVmax


EMC Vmax System

Storage

No. of Volumes are 256Each Volume size 68GBTotal Capacity= 17408

GB

HP-UX Host

Logical Layout during migration

EMC - VMAX IBM XIV

ImplementSVC based

mirroring

(for Vdisk migration)

Mdisk Group 0 Mdisk Group 1

1 2 3 4

1 2 3 4

1 2 3 4

1 2 3 4

Virtual Disk

Virtual Disk




c. Verify another the copy exists and status of copy progress.

d. Default copy rate is 2MB/sec for each volume (AS copy rate set to 50

only). Change the copy rate as per your requirement at any time

during Vdisk mirroring.

e. Verify status of copy progress.




f. Split the vdisk mirror relationships for all the volumes.

Copy 1

IBM XIV Gen2


48 Numbers of LUNs from

IBM XIV single pool

Size of each LUN = 1632 GB



HP-UX Host

Logical Layout

IBM XIV

Implement SVC based

mirroring

(for Vdisk migration)

Mdisk Group 1

1 2 3 4

1 2 3 4

1 2 3 4

1 2 3 4

Virtual Disk

Virtual Disk




Resources

These Web sites provide useful references to supplement the informationcontained in this document:

IBM SVC Info Center http://pic.dhe.ibm.com/infocenter/svc/ic/index.jsp

Implementing the IBM SVC V6.3

http://w3.itso.ibm.com/abstracts/sg247933.html?Open

Using the SVC for Business Continuity

http://www.redbooks.ibm.com/abstracts/sg247371.html?Open

http://pic.dhe.ibm.com/infocenter/svc/ic/index.jsp











Trademarks and special notices

© Copyright IBM Corporation 2012. All rights Reserved.

References in this document to IBM products or services do not imply that IBM intends to make them

available in every country.

IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business

Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked

terms are marked on their first occurrence in this information with a trademark symbol (® or ™), these

symbols indicate U.S. registered or common law trademarks owned by IBM at the time this information

was published. Such trademarks may also be registered or common law trademarks in other countries. A

current list of IBM trademarks is available on the Web at "Copyright and trademark information" at

www.ibm.com/legal/copytrade.shtml.

s vc based migration

Documents