Volume Migration Using Svc 2.1 July2005

7/26/2019 Volume Migration Using Svc 2.1 July2005

1/52

SVC VOLUME MIGRATION

Copyright IBM 2004 1

The information, tools and documentation (Materials) are being provided to IBM customers toassist them with customer installations. Such Materials are provided by IBM on an as-is basis.

IBM makes no representations or warranties regarding these Materials and does not provide anyguarantee or assurance that the use of such Materials will result in a successful customer installation.

MATERIAL UPDATED ON JULY 2005, IT REFLECTS CHANGES/FIXES ON THE

SAN VOLUME CONTROLLER CODE 2.1 and the ICAT CONSOLE 2.1.

ADDITIONAL TEST SCENARIOS WILL BE ADDED AS NECESSARY TO CLARIFY NEW

AVAILABLE FUNCTIONS.


2/52



DISK VOLUME M IGRATION USING THE SAN VOLUME CONTROLLER

WHI TE PAPER

The purpose of this paper is to provide detailed, step-by-step instructions on the migration of SAN attached

disk volumes to a virtualized environment using the IBM SAN Volume Controller (SVC, SIS or SVC forCisco MDS).

The current IBM publications (SVC Redbook SG24-6423 and the SVC Configuration Guide SC26-7543)provide some detail on migration, but this critical function has to be clearly understood and documented to

enable a successful implementation of IBM Virtualization using the SVC family of products.

This paper is intended for people who are familiar with the SVC, but need a practical example to guide themthrough the steps of how to migrate from an existing SAN environment to a SVC virtualized environment.

FIGURE 1 shows the lab environment, in which a LUN is assigned to a Windows 2000 Server from an ESSModel 800 storage system. The LUN is seen by Windows as a basic disk by default and can be converted to a

dynamic disk if desired. In this whitepaper dynamic disks will be used. The disk is formatted and the volume

is labeled as H:\WIN2KAPPL..


3/52



Here is the way LUN H:\WIN2KAPPLlooks to the Win2K Server before we start the virtualization

migration:

Notice that the WIN2KAPPL(H: disk) comes from the 2105-800(ESS_800) machine.


4/52



These are the contents of the H:\WIN2KAPPLdisk provided by the ESS_800:

Capacity: 1.86GB, 121 MB being used.


5/52



To perform a SAN attached disk migration to a virtualized environment; the following 5 steps need to take

place beforewe start using the IBM SAN Volume Controller:

1) Using the SAN fabric zoning tool (any of the supported switches tools), create an SVC_STORAGEZonethat includes the ESS_800, the FAStT900 and the SVC Fibre Channel adapters (all 4 in each node).

2) Create an additional SVC_HOST Zonethat includes the Win2K Server (SAN340_1)used in ourenvironment to represent the HOST, and the SVC Adapters (2 FC adapters, one from each SVC nodeshould be sufficient).

3) Activate the zone changes so they are ready when needed.

4) Shutdown the Win2K Server (SAN340_1), so the operating system is not aware of the LUN changesthat take place during the disk migration to SVC.

5) Using the ESS Specialist, un-assign the WIN2KAPPLLUN from the Win2K Server FC adapter, andassign it to all the SVC FC adapters in each node, as shown in FIGURE 2.


6/52



Having the environment ready by performing the previous 5 steps we can start the virtualization process using

the SVC master console (in this paper we assume familiarity with the SVC and its user interface).

NOTE: IF YOU NEED INFORMATION ON HOW TO VIRTUALIZE A LUN ON A

UNIX ENVIRONMENT, PLEASE REFERENCE THE APPENDIX ITEM 3 ON THIS

PAPER.

6) The first task is to find the newly attached LUN from the ESS_800. So under My Work we click onWORK WITH MANAGED DISKS and click on MANAGED DISKS and the following panel is

displayed:

:

Notice that there are 3 pages of Managed Disks. We look for the new LUN and dont find it, so we continue

with step 7.


7/52



7) We execute the DISCOVER MDISKSfunction and click GO. After the SVC discovers the newlyassigned disk (in our case MDISK5) it will appear with Status=ONLINE andMode= UNMANAGED.

NOTE:Sometimes the newly assigned disk is recognized dynamically, so there is no need for the

DISCOVER function, so make sure you look for the unmanaged disk that you acquired.

In our example, MDISK5is the same LUN that was previously allocated to the SAN340_1Win2K

Server, so all the files and data are still intact.

8) A good practice we recommend is to rename the disks so they make more sense to your installation, in ourexample, MDISK5 will be renamed using the function RENAME AN MDISK. The new name is

WIN2K_IMAGE.


8/52



9) In this step we will create an IMAGE MODE vDisk.

On the same Managed Disks panel, we select the WIN2K_IMAGEdisk, and execute the CREATE A

VDISK IN IMAGE MODE function. This will trigger an SVC wizard that needs to be followed carefully.

NOTE:ALL MANAGED DI SKS HAVE TO BE ASSOCIATED WI TH A MANAGED DI SK GROUP,

BUT WE SUGGEST THAT YOU CREATE AN MDG WITHOUT ANY DISKS AND NAME IT

MY_IMAGES_GROUP OR ANY OTHER NAME THAT MAKES SENSE I N YOUR

ENVIRONMENT.

See Appendix item 5 (COMMENTS ON MDG FOR IM AGE MODE VD ISKS)

for a step-by-step process to create this Managed Disk Group.

MOST PEOPLE ALREADY HAVE MANAGED DI SK GROUPS DEF INED, IN

THAT CASE, PROCEED WITH THE FOLLOWING I NSTRUCTIONS.


9/52



The first panel labeled CHOOSE AN I/O GROUP AND MANAGED DISK GROUP merits a

discussion to clarify the values on the different fields.

The flag Let the system choose a preferred node and I/O group should be checked (that is the default).

In our case, the defaults were used, which are the correct choice in most cases.

The field SELECT THE MANAGED DISK GROUP will allow us to associate the vDisk we arecreating with a specific managed disk group. In our lab we already had several Managed Disk Groups,

so we selected from them the ESS800_GROUP,and clicked Next.

NOTE: When creating an IMAGE MODE vDisk, we dont use storage from the selected MDG, but justpick the extent size associated with that pool (Managed Disk Group). The extent size will be important

when our IMAGE disk is migrated to a totally virtualized vDisk.

SEE APPENDIX ITEM 4 (COMMENTS ON EXTENT SIZE REQUIERMENTS ON VDISK MIGRATION).


10/52



Notice that the type of virtual disk is Image, and that the number of vDisks is already selected with a

value of 1. We click NEXT to continue.


11/52



We chose the name WIN2K_DISKfor the Virtual Disk. We click NEXT.


12/52



The panel above shows that the Image-Mode vDisk will be created from the WIN2K_IMAGEMdisk,which was originally attached from the ESS_800 to the Win2K Server. We click NEXT.

The panel above is a summary of the process to create our Image disk.

We click finish to create the WIN2K_DISK.


13/52



The vDisk was successfully created, as shown in the above panel.

10)On the SVC Console, we will select Work with Virtual Disks, and select Hosts, to create the Host that willrepresent the Win2K Server; we chose the same name that Windows has for that machine (SAN340_1).

The following panel shows that SAN340_1is already created, and has one port WWPN available. This

was possible by the SVC_HOST Zonewe created in step 2.


14/52



11) The next step will be to map the image vDisk to the WIN2K Server called SAN340_1.

We select the SVC console function WORK WITH VIRTUAL DISKS, and select VIRTUAL DISKS.

Find the image vDisk, in our example called WIN2K_DISK, select it and execute the function MAP

vDisk TO A HOST, as shown below.


15/52



The SVC Console shows the following display with a list of possible hosts which can be owners of this

vDisk.We select SAN340_1

At this time, we should start the SAN340_1host(remember it was shutdown to allow the storage

change, from ESS_800 to SVC).

NOTE: Once the SAN340_1 is up and runni ng, it wil l have the Vir tual D isk WIN2K_DI SK attached

and any addit ional SVC migrati on, disk expansion, etc. will NOT require the Win2K Server to be down.


16/52



The following chart summarizes all the steps that we took to create an Image Disk and attach it to the

Win2K Server.


17/52



To verify the Virtualization operation was a success, we select the Windows function COMPUTERMANAGEMENT, and click DISK MANAGEMT, to display the status of the SAN340_1disks.

In our example, notice the original H: disk is back, but now instead of being provided by the ESS_800, itcomes from 2145 (SVC machine number).

NOTE: In some cases with Windows, the disk (in our case Disk 3), will appear offline. If that is the case,right click on area labeled Disk 3, and select REACTIVATE DISK. This will bring the disk online will all

the appropriate attributes.


18/52



Notice the WIN2KAPPLcontents provided by the SVC Image disk; match perfectly the original contents

when the disk was directly attached to the ESS_800: Capacity of 1.86 GB, 121 MB being used.


19/52



The last step to complete the Virtualization process will be to make the IMAGE disk part of a virtualized

pool. In our example the image disk associated with ESS_800Storage, will be transferred to FastT900based storage.

If our original disk had been on an EMC Symmetrix, these same steps would apply, so we could migrate

from EMC to ESS, FastT, Hitachi, etc.

The following chart summarizes the process to migrate from one type of storage to another:


20/52



13) The migration of SVC Virtual disks from one pool (Managed Disk Group) to another is a very simple

command done in the Virtual Disks panel, as you can see below. The most important issue is that thismigration of the storage will be done under the covers by the SVC, so the owning host (in our case

SAN340_1) will NEVER loose connectivity with the LUN while it is being migrated.

We find our vDisk called WIN2K_DISK, select it and issue the MIGRATE VDISK function, as seenabove, notice the type is IMAGE, and the Mdisk Group Name that is associated with is ESS800_GROUP.


21/52



The following panel is displayed, showing a list of available target Managed Disk Group, where the Image

disk will migrate to, in our case FastT900_MIGRAT.Another selection required, is the priority of this migration (number of threads) 1 being low and 4 being

high. This priority will be highly dependent on the workload taking place at the moment of migration.

In our case 4 Threads, the highest priority, is the chosen value.


22/52



Notice on the screen capture below that the WIN2K_DISK, now has a type of STRIPED, and that it

belongs to the Mdisk Group Name FastT900_MIGRAT.This migration means that all the data that was in one LUN was moved to a group of multiple LUNs that

are part of the FastT900_MIGRAT, and the data is striped across all those LUNs, which in most cases

will increase performance.


23/52



This screen shows that the data in the Windows Server, which now is being provided by the SVC using

multiple FastT900 based disks, looks EXACTLY the same as before the migration.Capacity: 1.86 GB, 121 MB being used.


24/52



APPENDIX:

1) COMMENTS ON THE DOCUMENT:As mentioned on the introduction, this paper is a detailed step-by-step instruction on how to migrate SANattached storage to a Virtualized environment. People with little experience on the SVC should be able tofollow the logical sequence of events to make the migration possible. For those more experienced users,

this document could be a reference guide to verify their own process. If you have any comments or

suggestions, please send a note [email protected].

2) COMMENTS ON THE TEST SCOPE:The examples used to illustrate the migration apply specifically to a Windows 2000 host, but they can be

used for all other operating systems supported by the SVC.

We should point out that the outage of the Windows host in our example took only a matter of minutes,so the impact of having to shutdown some server types should not be a big concern.

Another area that is important to point out, is that we used the SVC ICAT console to perform themigration, but all the functions used, are also available on the Command Line Interface, so many of these

tasks could be scripted to automate the Virtualization.

3) COMMENTS ON VIRTUALIZING A LUN ON A UNIX ENVIRONMENT:To virtualize a SAN attached volume, originally attached to an AIX machine, the following steps should

take place:1) UNMOUNT THE FILE SYSTEM (release the Disks from AIX)

2) VARY OFF VOLUME GROUP (release the SCSI reserve on the LUNs)

3) EXPORT VOLUME GROUP (remove Volume Group and File System from the OS)4) Assign original LUN to SVC (Using ESS Specialist, SM8 or other tool)

5) Discover the new Managed Disk under SVC

6) Create an Image Mode vDisk on SVC7) Map the vDisk to the AIX host on the SVC.

8) RUN CFGMGR (discover new environment)

9) IMPORT VOLUME GROUP (recover the Group and File System definitions)

10) MOUNT THE FILE SYSTEM11) DONE!!!! (At this point the original file system is available for access)

NOTE: We are not documenting the tasks needed to handle multipaths, which in most cases will require

the installation of SDD to replace the multipathing software used to connect directly to the

SAN storage.

There are several AIX tasks, which are not documented in this section, because they are considered

part of the normal housekeeping of the system.

.


25/52



4)COMMENTS ON EXTENT SIZE REQUIREMENTS ON vDisk MIGRATION:The extent size is very important in our examples migration from ESS to FastT, because having the

SAME EXTENT size, is a requirement to migrate from one pool (Managed Disk Group) to another.

Because of this requirement, we recommend that you try to set a common extent size for all the Manageddisk groups.

The SVC Redbook states that a value of 32 MB (128 TB) or 64 MB (256 TB) can be the best trade-off

between performance and capacity.

5) COMMENTS ON MDG FOR IMAGE MODE VDISKs:

If you are creating an IMAGE MODE vDisk for the first time, the following instructions should provide aguide to make your life easier.

Note: the Mdisk Candidates in thi s panel, poin ted by theblue arrows. We DO NOT add any of them

to our group, as that woul d make a pool, and destroy the data in those disks. We just want an empty

Group. We click Next> to continue


26/52



We select an Extent Size of 64MB and click next

We click finish to create the Managed Disk Group, notice there are ZERO managed disks in thisgroup.


27/52



This section of the migration document will address new image mode migration capabilities

available in SVC 2.1.We will start with a Windows 2000 Server that has a 15 gig LUN allocated from a DS4300,

The environment is illustrated in figure 1:


28/52



Here is a display of the Windows Z: disk, called SVC21_MIGR, and its properties

Notice on the Disk2 Properties that the 15 gig LUN came from DS4300 (1722-600).


29/52



Our objective is to use the SVC 2.1, to help us migrate the Windows disk from DS4300 storage to

FastT200, as this disk is of low importance and should be moved to less expensive storage.The first step is to allocate the existing disk to the SVC. In order to do that, we shutdown the

Win2K system, and using the SM8 management tool, we assign the LUN we want to migrate to the

SVC.

NOTE: After the LUN is unassigned from the Win2K host, we can reactivate this host at any time.We show this process in Figure 2:


30/52



We are now working with the SVC Console, and when we issue a command on the Managed Diskspanel to Discover Mdisks, we find the 15 gig LUN that was part of Windows, available for

Virtualization. We keep our practice of renaming the Mdisks to a meaningful name, so we

rename the Mdisk from mdisk16 to SVC21_MIG_MDISK, for easier identification.

The first step we take to virtualize the LUN is to create an Image Mode disk, to preserve all the data

that was available in the Windows Z: disk called SVC21_MIGR.


31/52



To set the attributes of the new virtual image mode vDisk, we select to keep the same name as the

Original Windows disk, because it is the first Image Mode vDisk that we handle, we accept thedefault of Create an Empty Managed Disk Group (remember the only attribute we take from the

MDG is the extent size). The panel below also shows that the Mdisk SVC21_MIG_MDISK is thebase for our Image Mode vDisk


32/52



We give the name MIGRATION_GROUP to the newly created Managed Disk Group

We select 64MB as the extent size, as we decided this is a good value for our environment, we

decided to have ALL Managed Disk Groups with this extent value, so we can move and migrateamong all of them.

We keep all the defaults and select as highlighted below the MIGRATION_GROUP MDG.


33/52



Here is the result of our SVC21_MIGR Image Mode vDisk creation

Now we only need to map the Image Mode vDisk to SAN340_1 as shown on Figure 3


34/52



Mapping the Image Mode vDisk to the Windows 2000 host is accomplished with the following

command:


35/52



On the Windows host SAN340_1, we go to the Disk Management function and issue a rescan to

recover the SVC21_MIGR disk, as shown below, we recover a disk but it shows offline.

We click right button to get the following properties, so we can Reactivate Disk to allow

access to Windows. You see in the panel below, that the Windows disk kept all the attributes,like Drive letter (Z:), name (SVC21_MIGR) and the 15 GIG size.


36/52



You will see that in the Disk Properties, it shows that the disk came from 2145, which

identifies the SVC machine number.


37/52



You can verify that the contents of the SVC21_MIGR disk are exactly the same as they were

when the disk was provided by the DS4300.


38/52



IMAGE MODE TO IMAGE MODE MIGRATION, AND

REMOVAL OF FastT200 DISK FROM THE SVC CONTROL

Up to this point, creating an Image Mode vDisk has been the same as previous releases ofSVC. In this section we will use the SVC2.1 function to migrate an Image Mode vDisk in

Image Mode format, in that manner allowing the File to be moved to different storage (in ourexample we will move it to FasT200), and also very important, if we so desire, we can takethat migrated Image Mode LUN, and give it DIRECTLY to the host, removing any

dependency to have the data under SVC. This function allows a very efficient way to provide

storage migration, with a minimal impact to the supported hosts.

Our environment is describer in Figure 4


39/52



Using the SM8 management tool for FastT, we allocated a 15 gig LUN, from FastT200

storage to the SVC. This new LUN will be used as our target in the migration from DS4300based storage to FastT200.

We issue a Discover MDisks to rescan the Fibre Channel network and we find a new

Managed Disk, that we immediately renamed SVC21_MIG_F200

We will start using the new SVC 2.1 function called Migrate to an Image Mode vDisk, so

we select our SVC21_MIGR vDisk as the source. During the migration, the Win2K host will

be able to access information without any impact of the major changes happening under theSVC control. We will move the data from DS4300 to FastT200 totally transparent to the

Win2K Host.


40/52



The target of the Image Mode vDisk migration is selected below, as we mentioned before,this is the LUN that was allocated to the SVC from the FastT200, and the one we named

SVC21_MIG-F200.

We will associate the SVC_MIG_F200 to the MIGRATION_GROUP MDG, so it also gets

the attribute of 64MEG Segment Size, like the Source LUN so it can be migrated.


41/52



Here is the summary of our Image to Image Migration: We will take the extents and data

associated with SVC21_MIGR (on the DS4300 MDSIK called SVC21_MIG_MDISK) and

move it to a FastT200 based MDISK called SVC_MIG_F200.


42/52



While migrating from one kind of storage to another, we issued reads and writes to the

Windows disk, while it was migrating on the SVC, and verified that all the new data wasreflected in the new storage.

We started an unzip to create a new file called BIG_ZIP_CONCURRENT


43/52



The following panel indicates that the IMAGE to IMAGE migration was successful

This panel shows that the Image Mode vDisk is now running on storage provided by the

SVC21_MIG_F200 Managed Disk, and the supporting storage come from the FastT200Controller.


44/52



REMOVAL OF FastT200 DISK FROM THE SVC CONTROL

If we need to provide the FastT200 disk, directly to the Windows host, we would need to

perform the following additional steps:

1) Shutdown the SAN340_1 host. We are going to change the storage source for theSVC21_MIGR disk, so we need to do that with the operating system down.

2) Unmap the SVC21_MIGR vDisk from the SAN340_1 Host, using the SVC Console.


45/52



3) Delete the SVC21_MIGR vDisk(as seen below) to insure the SVC writes the cache tothe disk, before we unattach the MDISK (LUN) from the SVC, using SM8.

4) Unmap the SVC21_MIG_F200 Mdisk from the SVC using the FastT Management

tool (SM8), and map it to SAN340_1.

5) Power on the SAN340_1 Host, access disk management to see the status of the disk.The SVC21_MIGR disk might be offline, like show below, in that case, we reactivate the

Windows dynamic disk.


46/52



Once the disk is active, we can see that all the attributes, and the files that were created are

available to Win2K, but now the disk comes directly from the FastT200, with all SVC

dependencies removed.


47/52



MIGRATION FROM AN SVC STRIPPED vDisk TO AN IMAGE

MODE vDisk.

Using the SVC Console, we start by creating a 1GB vDisk from the DS4300 MDG, and mapit to the SAN340_1 Host.

In the SAN340_1 disk, we format the disk (Y :) and give it the name SVC21_STRIP, we add

Data so we use 679 Meg.


48/52



We initiate a migration from the striped SVC21_STRP_TEST vDisk to an Image Mode

vDisk, so we can later assign that disk directly to the SAN340_1.

Our Target disk for the image will be 1 GIG LUN, called IMAGE_STR_TGT, this Mdiskcomes from the DS4300.


49/52



We need to assign the Mdisk to a Managed Disk Group (MDG) so we can get the attributes

like extent size, so we picked the one labeled another migration Mdisk Group.

We assign 4 threads to speed up the migration, verify all our parameters, and execute the

migration.


50/52



The following steps are required if we want to provide the disk directly from the DS4300, to

the Windows host. These are the same steps as we saw in our previous example:

1) Shutdown the SAN340_1 host

2) Delete the Host mapping on the SVC

3) Delete the vDisk, to insure that the cache is written to the disk, before weunattach from the SVC, using SM8.

4) Unassign image LUN from SVC, and assign directly to the Win2K host, using SM8.5) Power-on the SAN340_1 host.

Here is the status of the LUN in Windows, showing that now it comes from the DS4300

(1722-600):


51/52



We verify that the contents of the LUN from FasT600 are exactly the same as they were

under the SVC vDisk, and they are.

We need some additional housekeeping on the SVC Console:

6) Issue a Discover Mdiskscommand on the SVC Mdisks panel, so the fibre channelnetwork is rescanned

7) Issue a Refreshon the SVC Mdisks panel, so the console reflects theIMAGE_STR_TGT Managed Disk (LUN) is not allocated anymore to the SVC, as it isnow directly assigned by the FastT management tool, to the SAN340_1 Host.


52/52


Date post:	01-Mar-2018
Category:	Documents
Upload:	hiehie272
View:	215 times
Download:	0 times

Volume Migration Using Svc 2.1 July2005

Documents