The information, tools and documentation ( Materials ) are being provided to IBM customers to assist 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 any guarantee 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. Copyright IBM 2004 1
DISK VOLUME MIGRATION USING THE SAN VOLUME CONTROLLER WHITE 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 for Cisco 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 them through 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 ESS Model 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.. Copyright IBM 2004 2
Here is the way LUN H:\WIN2KAPPL looks to the Win2K Server before we start the virtualization migration: Notice that the WIN2KAPPL (H: disk) comes from the 2105-800 (ESS_800) machine. Copyright IBM 2004 3
These are the contents of the H:\WIN2KAPPL disk provided by the ESS_800: Capacity: 1.86GB, 121 MB being used. Copyright IBM 2004 4
To perform a SAN attached disk migration to a virtualized environment; the following 5 steps need to take place before we start using the IBM SAN Volume Controller: 1) Using the SAN fabric zoning tool (any of the supported switches tools), create an SVC_STORAGE Zone that includes the ESS_800, the FAStT900 and the SVC Fibre Channel adapters (all 4 in each node). 2) Create an additional SVC_HOST Zone that includes the Win2K Server (SAN340_1) used in our environment to represent the HOST, and the SVC Adapters (2 FC adapters, one from each SVC node should 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 changes that take place during the disk migration to SVC. 5) Using the ESS Specialist, un-assign the WIN2KAPPL LUN from the Win2K Server FC adapter, and assign it to all the SVC FC adapters in each node, as shown in FIGURE 2. Copyright IBM 2004 5
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 on WORK 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 don t find it, so we continue with step 7. Copyright IBM 2004 6
7) We execute the DISCOVER MDISKS function and click GO. After the SVC discovers the newly assigned disk (in our case MDISK5) it will appear with Status=ONLINE and Mode= 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, MDISK5 is the same LUN that was previously allocated to the SAN340_1 Win2K 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 our example, MDISK5 will be renamed using the function RENAME AN MDISK. The new name is WIN2K_IMAGE. Copyright IBM 2004 7
9) In this step we will create an IMAGE MODE vdisk. SVC VOLUME MIGRATION On the same Managed Disks panel, we select the WIN2K_IMAGE disk, 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 DISKS HAVE TO BE ASSOCIATED WITH A MANAGED DISK 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 IN YOUR ENVIRONMENT. See Appendix item 5 (COMMENTS ON MDG FOR IMAGE MODE VDISKS) for a step-by-step process to create this Managed Disk Group. MOST PEOPLE ALREADY HAVE MANAGED DISK GROUPS DEFINED, IN THAT CASE, PROCEED WITH THE FOLLOWING INSTRUCTIONS. Copyright IBM 2004 8
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 are creating 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 don t use storage from the selected MDG, but just pick 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). Copyright IBM 2004 9
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. Copyright IBM 2004 10
We chose the name WIN2K_DISK for the Virtual Disk. We click NEXT. Copyright IBM 2004 11
The panel above shows that the Image-Mode vdisk will be created from the WIN2K_IMAGE Mdisk, 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. Copyright IBM 2004 12
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 will represent the Win2K Server; we chose the same name that Windows has for that machine (SAN340_1). The following panel shows that SAN340_1 is already created, and has one port WWPN available. This was possible by the SVC_HOST Zone we created in step 2. Copyright IBM 2004 13
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. Copyright IBM 2004 14
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_1 host (remember it was shutdown to allow the storage change, from ESS_800 to SVC). NOTE: Once the SAN340_1 is up and running, it will have the Virtual Disk WIN2K_DISK attached and any additional SVC migration, disk expansion, etc. will NOT require the Win2K Server to be down. Copyright IBM 2004 15
The following chart summarizes all the steps that we took to create an Image Disk and attach it to the Win2K Server. Copyright IBM 2004 16
To verify the Virtualization operation was a success, we select the Windows function COMPUTER MANAGEMENT, and click DISK MANAGEMT, to display the status of the SAN340_1 disks. In our example, notice the original H: disk is back, but now instead of being provided by the ESS_800, it comes 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. Copyright IBM 2004 17
Notice the WIN2KAPPL contents 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. Copyright IBM 2004 18
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_800 Storage, will be transferred to FastT900 based 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: Copyright IBM 2004 19
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 this migration 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 seen above, notice the type is IMAGE, and the Mdisk Group Name that is associated with is ESS800_GROUP. Copyright IBM 2004 20
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. Copyright IBM 2004 21
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. Copyright IBM 2004 22
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. Copyright IBM 2004 23
APPENDIX: 1) COMMENTS ON THE DOCUMENT: As mentioned on the introduction, this paper is a detailed step-by-step instruction on how to migrate SAN attached storage to a Virtualized environment. People with little experience on the SVC should be able to follow 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 to gfuentes@us.ibm.com. 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 the migration, 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 SVC 7) 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 SYSTEM 11) 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. Copyright IBM 2004 24
4) COMMENTS ON EXTENT SIZE REQUIREMENTS ON vdisk MIGRATION: The extent size is very important in our example s 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 Managed disk 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 a guide to make your life easier. Note: the Mdisk Candidates in this panel, pointed by the blue arrows. We DO NOT add any of them to our group, as that would make a pool, and destroy the data in those disks. We just want an empty Group. We click Next> to continue Copyright IBM 2004 25
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 this group. Copyright IBM 2004 26
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: Copyright IBM 2004 27
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). Copyright IBM 2004 28
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: Copyright IBM 2004 29
We are now working with the SVC Console, and when we issue a command on the Managed Disks panel 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. Copyright IBM 2004 30
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 the default 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 the base for our Image Mode vdisk Copyright IBM 2004 31
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 migrate among all of them. We keep all the defaults and select as highlighted below the MIGRATION_GROUP MDG. Copyright IBM 2004 32
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 Copyright IBM 2004 33
Mapping the Image Mode vdisk to the Windows 2000 host is accomplished with the following command: Copyright IBM 2004 34
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. Copyright IBM 2004 35
You will see that in the Disk Properties, it shows that the disk came from 2145, which identifies the SVC machine number. Copyright IBM 2004 36
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. Copyright IBM 2004 37
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 of SVC. 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 our example we will move it to FasT200), and also very important, if we so desire, we can take that 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 Copyright IBM 2004 38
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 DS4300 based 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 the SVC control. We will move the data from DS4300 to FastT200 totally transparent to the Win2K Host. Copyright IBM 2004 39
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. Copyright IBM 2004 40
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. Copyright IBM 2004 41
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 was reflected in the new storage. We started an unzip to create a new file called BIG_ZIP_CONCURRENT Copyright IBM 2004 42
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 FastT200 Controller. Copyright IBM 2004 43
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 the SVC21_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. Copyright IBM 2004 44
3) Delete the SVC21_MIGR vdisk (as seen below) to insure the SVC writes the cache to the 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. Copyright IBM 2004 45
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. Copyright IBM 2004 46
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 map it 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. Copyright IBM 2004 47
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 Mdisk comes from the DS4300. Copyright IBM 2004 48
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. Copyright IBM 2004 49
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 we unattach 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): Copyright IBM 2004 50
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 Mdisks command on the SVC Mdisks panel, so the fibre channel network is rescanned 7) Issue a Refresh on the SVC Mdisks panel, so the console reflects the IMAGE_STR_TGT Managed Disk (LUN) is not allocated anymore to the SVC, as it is now directly assigned by the FastT management tool, to the SAN340_1 Host. Copyright IBM 2004 51
Copyright IBM 2004 52