Technical Note P/N REV A02 June 3, 2010

Transcription

1 Best Practices for Nondisruptive Tiering via EMC Symmetrix Virtual LUN Technical Note P/N REV A02 June 3, 2010 This technical note contains information on these topics: Executive summary... 2 Introduction... 2 Tiered storage... 3 RAID Virtual Architecture... 4 Virtual LUN technology... 5 Virtual LUN migrations... 8 Management interface: SYMCLI Management interface: SMC Logging Operational examples Conclusion References

2 Executive summary Executive summary Introduction Information infrastructure must continuously adapt to changing business requirements. EMC Symmetrix Enhanced Virtual LUN Technology optimizes tiered storage strategies by easily re-tiering data as its value changes over time. Symmetrix Virtual LUN assists with system reconfiguration, performance improvement, and consolidation efforts all while maintaining vital service levels. Virtual LUN technology, enhanced with Enginuity 5874 for the Symmetrix VMAX Series, enables transparent, nondisruptive data mobility among storage tiers within the same array and between RAID protection schemes without impacting local or remote replication. Organizations can respond more easily to changing business requirements when using tiered storage in the array. Virtual LUN technology is supported for both open system and mainframe devices, and includes support for metavolumes. Virtual LUN technology offers two types of data movement: migration to unconfigured space and migration to configured space. In each case, the migration provides users the ability to move data between highperformance drives and high-capacity drives, or to populate newly added drives, with full inter-raid flexibility. Audience This technical note provides an in-depth look at the Virtual LUN technology feature for Symmetrix VMAX enterprise storage arrays. The intended audience includes system and storage administrators, customers, EMC staff, and partners who need to understand how to implement and leverage Virtual LUN technology. 2

3 Tiered storage Tiered storage Tiered storage is the practice of maintaining storage of varying performance and characteristics either among multiple arrays, or within the same array itself. Tiered storage gives administrators the flexibility to utilize their resources effectively by aligning hardware levels to appropriate information value. For example, data hot spots can be placed into higher performing hardware, providing better performance and user experience. The Symmetrix architecture enables storage administrators to consolidate multiple application tiers, server platforms, and connection types all in the same array without compromising performance, availability, or functionality. Symmetrix is the only storage array that can scale up to two petabytes (2 PB), enabling massive scalability and tiering within a single system, and providing significant cost savings through operational efficiencies. Data migration should not be overlooked in complex, expensive storage environments. Tiered storage is based on properly aligning resources with the ever-changing value of information, and storage systems have to dynamically react over time. From within the array, data migration gives life to tiered storage. Without it information remains on storage levels that do not correspond to its value. Tiered storage must also include the ability to freely move data among storage tiers to respond to rapidly changing information value and business needs. The challenge is that migration is normally associated with system downtime, which adversely affects the ability to meet service level agreements (SLAs). This issue prevents many storage administrators from effectively moving data because of their reluctance to disturb their system or create application downtime. Symmetrix Virtual LUN technology is an important tool to address this requirement by providing the essential ability to migrate data throughout the array easily and without downtime, thereby effectively merging storage consolidation with tiered storage. 3

4 RAID Virtual Architecture RAID Virtual Architecture RAID Virtual Architecture (RVA) is the new architecture employed in Symmetrix VMAX systems to implement RAID protection. RVA extends the design of RAID 6 used in the Symmetrix DMX-3 and DMX-4 storage arrays and in so doing provides a uniform implementation of all RAID protection schemes unprotected, RAID 1, RAID 5, and RAID 6. The RVA design abstracts all RAID protection types to a single mirror position for a given Symmetrix logical volume, thus freeing up device mirror positions for additional features, such as Virtual LUN migrations. As before, each Symmetrix logical device is represented in the array by four mirror positions M1, M2, M3, and M4. However, in Enginuity 5773 and earlier, certain RAID types RAID 1 and RAID 5 used two mirror positions, as shown in Figure 1. Figure 1 Enginuity 5773 local RAID protection types With Enginuity 5874 in Symmetrix VMAX, however, all local RAID protection types only consume one mirror position, as shown in Figure 2. 4

5 Virtual LUN technology Figure 2 Enginuity 5874 local RAID protection types RAID Virtual Architecture temporarily allows for two distinct RAID groups to be associated with a device. This feature allows for a Symmetrix logical volume to be migrated from one RAID group to another. Virtual LUN technology Virtual LUN technology enables transparent, nondisruptive data mobility for standard Symmetrix volumes between storage tiers and between RAID protection schemes. Virtual LUN can be used to populate newly added drives or move devices between high performance and high capacity drives, thereby delivering tiered storage capabilities within a single Symmetrix array. Migrations are performed while providing constant data availability and protection. Virtual LUN technology performs in-the-box tiered storage migration by migrating data from one RAID group to another. The migration is facilitated by the creation and movement of RAID groups, via online configuration change on the Symmetrix. RAID Virtual Architecture allows, for the purposes of migration, two distinct RAID groups, of different types or on different storage tiers, to be associated with a logical volume. In this way, Virtual LUN allows for the migration of data from one protection scheme to another, for example RAID 1 to RAID 5, without interruption to the host or 5

6 Virtual LUN technology application accessing data on the Symmetrix device. Virtual LUN can be used to migrate standard Symmetrix devices and metadevices of any emulation FBA, CKD, and iseries. Migrations can be performed between all drive types including high-performance enterprise Flash drives, Fibre Channel drives, and large capacity SATA drives. Data can be migrated to either unconfigured or configured space. In the case of the migration to unconfigured space, a target RAID group is created from the free pool in the array and migrated to. When complete, the original RAID group is deleted and the storage returned to the free pool. When migrating to configured space, an existing, but unused, Symmetrix device is specified as a target and the source device migrated to the physical storage occupied by the target device. This target device can either be specified by the user or automatically selected by the Symmetrix. Following the migration, the device specified as the target will occupy the storage originally associated with the device being migrated. An ivtoc is then performed on the target device leaving its original data inaccessible. Note: In the case of migrating to configured space, the target device specified must be of the same size and configuration as the source device being migrated. If migrating a metadevice, a metadevice of the same size and configuration must be specified, or a number of individual devices equal in size and quantity of the metamembers being migrated. For the purposes of a migration, either the protection type or the storage tier must change, or both. Symmetrix volumes of any protection can be migrated to any other supported RAID protection with one exception protected devices may not be migrated space that is unprotected. 6

7 Virtual LUN technology Table 1. Allowed RAID protection changes Source Volume Protection Available Target Protection Unprotected Unprotected*, RAID 1 RAID 5 (3+1), RAID 5 (7+1) RAID 6 (6+2), RAID 6 (14+2) RAID 1 RAID 1*, RAID 5 (3+1), RAID 5 (7+1) RAID 6 (6+2), RAID (14+2) RAID 5 (3+1) RAID 1, RAID 5 (3+1)*, RAID 5 (7+1) RAID 6 (6+2), RAID (14+2) RAID 5 (7+1) RAID 1, RAID5 (3+1), RAID5 (7+1)* RAID 6 (6+2), RAID (14+2) RAID 6 (6+2) RAID 1, RAID 5 (3+1), RAID 5 (7+1) RAID 6 (6+2)*, RAID (14+2) RAID 6 (14+2) RAID 1, RAID 5 (3+1), RAID 5 (7+1) RAID 6 (6+2), RAID (14+2)* * migration to different physical disk group only Virtual LUN technology is fully interoperable with all other Symmetrix replication technologies SRDF, TimeFinder /Clone, TimeFinder/Snap, and Open Replicator. Virtual LUN migrations can be managed via the Symmetrix Management Console (SMC) graphical interface, or the Solutions Enabler Command Line Interface (SYMCLI). To perform a Virtual LUN migration, the following are required: Symmetrix VMAX Enginuity 5874 Solutions Enabler 7.0 Symmetrix Management Console 7.0 (optional) Symmetrix Optimization license key 7

8 Virtual LUN migrations Virtual LUN migrations Source criteria Target criteria Device files Solutions Enabler 7.0 introduces a new SYMCLI command, symmigrate, which can be used to perform and monitor Virtual LUN migrations. The source devices for the Virtual LUN migration can be specified in one of four ways: A device group A storage group A source file (SYMCLI) A single column of the devices to be migrated, or Two columns of devices pairing the source and target device(s) Manual selection (SMC) Manual selection of source devices, or Manual selection of exact source and target device pairs When migrating to unconfigured space the target storage is specified by the physical disk group, along with the desired RAID protection type. When migrating to configured space, the target storage can be specified by the destination disk group along with the desired RAID protection type, in which case Symmetrix Enginuity will automatically select appropriate target devices that fit the target criteria. The devices selected will be either unmapped and/or unmasked and so not in use on a host. Alternatively, user selected target devices can be included along with the source devices in a text file. When using exact pairings the RAID protection type and disk group are assumed. When migrating to unconfigured space, a source device file can be created listing the devices to be migrated in the single column. For example, to migrate devices 790, 791, 792, and 793 the following file could be created cat devices.txt

9 Virtual LUN migrations A similar file can be created when migrating to configured space if a target disk group is going to be used. However, if it is required to migrate the source devices to the locations of specific target devices then a device pairs file can be created. This file will consist of two columns, where the first column is the source device to be migrated, while the second column contains the target devices currently occupying the storage to be migrated to. In an example where devices 790, 791, 792, and 793 are being migrated to storage attached to devices 7A5, 7C6, 7D2, and 7D5, then the device pairs file would look like: cat dev_pairs.txt 790 7A C D D5 In this case, device 790 will be migrated to the storage currently associated with device 7A5, device 791 with device 7C6, and so on for the rest of the file. If migrating metadevices to configured space, the device pairs file can contain a list of target metadevices that are configured the same way as the source metadevices. Alternatively, this can be a comma-separated list of individual devices equal in size and number to the metamembers in the metadevice being migrated. In the case of the latter, the device pairs file would look like this: cat meta_pairs.txt 790 7A5,7A6,7A7,7A A9,7AA,7AB,7AC Sessions Migrations are submitted and managed as sessions a session name is specified when establishing the migration. Symmetrix supports up to 16 concurrent active and passive sessions. An active session is defined as a migration that has been established but has not yet completed. A passive session is a migration that has completed, but has not yet been terminated. The Symmetrix supports up to four concurrent active Virtual LUN migrations, although only one migration can be submitted at a given time. Once a migration has been established another migration can then be submitted. 9

10 Virtual LUN migrations Migration states Each migration session can have up to a maximum of 128 Symmetrix devices per Symmetrix VMAX Engine. A total of 128 devices per Symmetrix VMAX Engine can be part of active migration sessions on the Symmetrix at any given time. This means that a Symmetrix VMAX system with a single engine (two directors) can support up to 128 active device migrations, while a fully populated Symmetrix with eight engines (16 directors) can support up to 1,024 active, concurrent device migrations. If a migration session has been established to a Symmetrix containing a single engine, and it contains 128 devices, the migration state must reach Migrated prior to another migration session being established. Also, if the number of devices in a session being established will cause the Symmetrix to exceed 128 devices per engine, the establish will fail with an error. Note: When migrating metadevices each individual metamember counts toward the 128 device per engine maximum. There are six possible migration states: CreateInProg Indicates that the migration has been submitted to the Symmetrix and the initial configuration change creating or moving the destination RAID group is in progress. SyncInProg The data transfer from source RAID group to target is underway. Synchronized The data transfer process has completed. MigrInProg The second configuration change is being performed to promote the target RAID group to primary and repurpose the original storage. Migrated The data has been migrated and all configuration changes have completed. From this state the migration can be terminated. Failed The Symmetrix-based script responsible for managing the migration has failed and is no longer executing. In this state, customers should contact EMC support personnel for further assistance. 10

11 Virtual LUN migrations Migration to unconfigured space Migrating to unconfigured space will create new hypers, from free space, to be used as the target of the migration. Once the data transfer has been completed, the physical space previously associated with the migrated device will be returned to the free pool. In the following illustration, Symmetrix volume BE8 is locally protected as RAID 1 on Fibre Channel drives. It is also remotely protected via SRDF, as shown in Figure 3. The volume will be migrated to currently unconfigured storage on SATA drives, and will be locally protected as RAID 5. In performing the migration to unconfigured space the, five distinct stages are seen. Stage 1 Figure 3 shows the device to be migrated prior to the migration being established. Figure 3 Migration to unconfigured space: Stage 1 To establish the migration the volumes to be migrated are submitted to Symmetrix via Solutions Enabler SYMCLI or SMC. Stage 2 Upon submission, the external Symmetrix configuration lock (lock15) is placed on the array in order to perform the first of two configuration changes during the migration. Once the Symmetrix is locked, the target RAID 5 group is created on the destination storage and attached as a secondary mirror to the device being migrated. The RAID group is added in the first available mirror position, in this case the third mirror (M3) position, as shown in Figure 4. 11

12 Virtual LUN migrations Figure 4 Migration to unconfigured space: Stage 2 Once attached, the RAID group is completely invalidated to be synchronized from the primary mirror and the configuration lock is released. The release of the configuration lock allows other migrations, or configuration changes, to be run concurrently with the existing migration. Stage 3 As the secondary mirror was invalidated when it was associated with the volume, it is then synchronized from the primary mirror of the volume. Figure 5 shows the secondary mirror now synchronized with the primary mirror. Figure 5 Migration to unconfigured space: Stage 3 12

13 Virtual LUN migrations Stage 4 Following the completion of the synchronization, the Symmetrix configuration lock is acquired once again. Once locked, the volume configuration is updated to swap the primary and secondary roles of the attached RAID groups. In this case the original RAID 1 mirror is demoted to secondary, while the new RAID 5 mirror is promoted to be the primary mirror. This change is shown in Figure 6. Figure 6 Migration to unconfigured space: Stage 4 Stage 5 When the primary and secondary mirror roles are switched, the now secondary mirror is detached from the volume and the RAID group deleted. The space previously occupied by the RAID 1 group on the Fibre Channel storage is returned to the free pool, as illustrated in Figure 7. Figure 7 Migration to unconfigured space: Stage 5 At this time, the configuration lock is released, and the migration is 13

14 Virtual LUN migrations considered to be complete and can be terminated. Note: Following a migration, while the primary mirror may actually reside in a mirror position other than the M1 position on the Symmetrix, the SYMCLI output will always display the primary mirror as being in the M1 position. Migration to configured space When migrating to configured space, the Symmetrix will choose from existing RAID groups associated with other logical devices to migrate the data to. These target devices may not be in use, that is, unmapped and/or unmasked, on the array prior to or during the migration. Following the migration, data that may have existed on the target devices will no longer be accessible. In the following illustration, Symmetrix volume BE8 is locally protected as RAID 1 on Fibre Channel drives. It is also remotely protected via SRDF. The volume will be migrated to storage, on SATA drives, currently occupied by the RAID 5 protected volume AE7. As in the migration to unconfigured space, in performing the migration to configured space five distinct stages are seen. Stage 1 Figure 8 shows the volume to be migrated and the volume being migrated to prior to the migration being established. Figure 8 Migration to configured space: Stage 1 To establish the migration the volumes to be migrated are submitted to Symmetrix via Solutions Enabler SYMCLI or SMC. 14

15 Virtual LUN migrations Stage 2 Upon submission, the external Symmetrix configuration lock (lock15) is placed on the array in order to perform the first of two configuration changes during the migration. Once the Symmetrix is locked, the RAID 5 group associated with the target volume is made not ready, detached from the target volume, and attached to the device being migrated. The target RAID group is added in the first available mirror position, in this case the third mirror (M3) position, as shown in Figure 9. Figure 9 Migration to configured space: Stage 2 Once attached, the RAID group is completely invalidated to be synchronized from the primary mirror and the configuration lock is released. The release of the configuration lock allows other migrations, or configuration changes, to be run concurrently with the existing migration. Stage 3 As the secondary mirror was invalidated when it was associated with the volume, it is then synchronized from the primary mirror of the volume. Figure 10 shows the secondary mirror now synchronized with the primary mirror. 15

16 Virtual LUN migrations Figure 10 Migration to configured space: Stage 3 Stage 4 Following the completion of the synchronization, the Symmetrix configuration lock is acquired once again. Once locked, the volume configuration is updated to swap the primary and secondary roles of the attached RAID groups. In this case the original RAID 1 mirror is demoted to secondary, while the new RAID 5 mirror is promoted to be the primary mirror. This change is shown in Figure 11. Figure 11 Migration to configured space: Stage 4 Stage 5 When the primary and secondary mirror roles are switched, the now secondary mirror is detached from the volume and attached to the target device as its primary mirror, as illustrated in Figure

17 Virtual LUN migrations Figure 12 Migration to configured space: Stage 5 At this point, the RAID 1 group now associated with volume AE7 still has the original data that was available via volume BE8. Stage 6 Prior to completing the migration, the RAID group now associated with the target volume has an instant VTOC performed, thereby making the data contained inaccessible. Figure 13 Migration to configured space: Stage 6 At this time, the configuration lock is released, and the migration is considered to be complete and can be terminated. Note: Following a migration, while the primary mirror may actually reside in a mirror position other than the M1 position on the Symmetrix, the SYMCLI output will always display the primary mirror as being in the M1 position. 17

18 Virtual LUN migrations Replication technology interaction As previously stated, Virtual LUN technology is fully interoperable with all other Symmetrix replication technologies SRDF, TimeFinder/Clone, TimeFinder/Snap, and Open Replicator. Any active replication on a Symmetrix volume remains intact while the device is being migrated. Similarly, all incremental relationships are maintained for the migrated devices. What must be kept in mind, however, is that the Symmetrix will only allow one control operation to be executed against any given device at one time. This means that SRDF or TimeFinder control commands may not be run against a device while the migration request is being submitted, and vice versa. SRDF An RDF1 volume can be migrated while also actively replicating to an RDF2 volume, in either synchronous or asynchronous mode. Similarly, an RDF2 volume can be migrated while being replicated to by an RDF1 volume. However, an SRDF volume (R1 or R2) cannot be specified as the target volume in a Virtual LUN migration, regardless of SRDF pair state or mode of operation. TimeFinder/Clone The source volume of a TimeFinder/Clone session, or Clone emulation session, can be migrated using Virtual LUN. A volume that is a target device of a TimeFinder/Clone session, or a Clone emulation session, can also be migrated, provided that the target has been split or activated. A volume that is a source device of a native Clone session, or Clone emulation, cannot be specified as the target volume in a migration. Similarly, a target volume of a Clone session, in native or emulation mode, cannot be specified as the target volume in a Virtual LUN migration. In both cases, the Clone session would first need to be terminated. TimeFinder/Snap The source volume in a TimeFinder/Snap session can be migrated using Virtual LUN. A Snap source volume cannot be specified as the target device in a Virtual LUN migration, the session must first be terminated. Open Replicator for Symmetrix The control volume in an Open Replicator session, either push or pull, may be migrated using Virtual LUN. The Open Replicator control volume may not be specified as the target volume in a migration. 18

19 Virtual LUN migrations Limitations The following considerations apply to Virtual LUN migrations: Once submitted, a LUN migration cannot be canceled or aborted; however the migration can be effectively paused (see the following Performance section). Migration of Virtual Provisioning devices (Data or Thin devices) is not supported. Migration of TimeFinder/Snap devices (VDEV or SAVE devices) is not supported. Migration of SAVE devices for SRDF/A Delta Set Extension is not supported. Migration of internal devices such as SFS or Vault devices is not supported. The control host for the migration must be locally connected to the Symmetrix on which the migration is being performed. When migrating to configured space there must be sufficient unmapped/unmasked devices of the desired RAID protection type to complete the migration. When migrating to unconfigured space there must be sufficient unallocated space available to create the hypers of the desired RAID protection type. CKD striped metadevices can only migrate to other CKD striped metadevices, and that target protection type is restricted to RAID 1. Performance The data synchronization that occurs between the source RAID group and the target RAID group is performed as a copy process on the backend disk directors (DA) in the Symmetrix. Because of this, other copy processes running on the array, such as a TimeFinder/Clone copy session, may be impacted by the additional traffic. In this situation, because there is no facility to cancel or abort the migration, the copy process used by Virtual LUN can be slowed down to allow other tasks to complete in a more timely manner. The ability to manage the pace at which Virtual LUN migrates data from source to target is available through the Symmetrix Quality of Service (QoS) tools. Using the symqos command, a copy pace can be placed on the Virtual LUN copy process. The Virtual LUN data transfer is considered a mirror copy (MIR) operation, therefore, the command to set or change the copy pace, in this case to 8, on all devices contained in 19

20 Virtual LUN migrations device group app01, is: symqos g app01 set MIR pace 8 The pace value can be set as integer values between 0 and 16 inclusively, with 0 being the fastest and 16 being the slowest. The default QoS value is 0. Setting the pace value to 16 will allow the migration to synchronize approximately one track per minute, per device, effectively suspending the migration. Once the unrelated copy tasks have completed, the pace setting can be reset to 0. The QoS values can also be set via SMC. This can be done by rightclicking on the device group containing the devices to change QoS on. From the resulting menu select Replication, followed by QoS, as shown in Figure 14. Figure 14 Setting the QoS value via SMC 20

21 Virtual LUN migrations Selecting target storage In the resulting popup window, also shown in Figure 14, the Operation Type is set to Mirror Copy and a copy pace value is set via the dropdown. Before migrating devices to a different storage tier, or to a different RAID protection type, it should first be determined if there is sufficient storage in the destination disk group. In the case of migrating to unconfigured space this entails looking at the free space available in each disk group configured on the Symmetrix. For a migration to configured space it must be determined if there are sufficient unallocated devices of the desired protection type, and capacity, in the destination disk group. Solutions Enabler SYMCLI provides multiple commands that assist in providing this information. Unconfigured space To list all physical drives, and the free space on each drive, grouped by physical disk group, in the array, run: symdisk list sid 1254 by_diskgroup Symmetrix ID : Disks Selected : 240 Capacity(MB) Ident Symb Int TID Vendor Type Hypers Total Free Actual Disk Group 0: DF-7A 07A C 0 SEAGATE T DF-7A 07A C 2 SEAGATE T DF-7A 07A C 4 SEAGATE T DF-7A 07A C 6 SEAGATE T DF-7A 07A C 8 SEAGATE T DF-7A 07A C A SEAGATE T DF-7A 07A D 1 SEAGATE T DF-7A 07A D 3 SEAGATE T Disk Group 1: DF-7A 07A C C SATAHGST N01THGK DF-7A 07A C E SATAHGST N01THGK DF-7A 07A D B SATAHGST N01THGK DF-7A 07A D D SATAHGST N01THGK DF-8A 08A C B SATAHGST N01THGK DF-8A 08A C D SATAHGST N01THGK DF-8A 08A D C SATAHGST N01THGK DF-8A 08A D E SATAHGST N01THGK DF-9A 09A C C SATAHGST N01THGK

22 Virtual LUN migrations DF-9A 09A C E SATAHGST N01THGK To list all physical drives in a particular disk group on the array, run: symdisk list sid 1254 disk_group 1 Symmetrix ID : Disks Selected : 240 Capacity(MB) Ident Symb Int TID Vendor Type Hypers Total Free Actual DF-7A 07A C C SATAHGST N01THGK DF-7A 07A C E SATAHGST N01THGK DF-7A 07A D B SATAHGST N01THGK DF-7A 07A D D SATAHGST N01THGK DF-8A 08A C B SATAHGST N01THGK DF-8A 08A C D SATAHGST N01THGK DF-8A 08A D C SATAHGST N01THGK DF-8A 08A D E SATAHGST N01THGK DF-9A 09A C C SATAHGST N01THGK DF-9A 09A C E SATAHGST N01THGK To list the available gaps (contiguous blocks of free space) on all drives in a specified disk group, run: symdisk list sid 1254 disk_group 1 v hypers gaps Symmetrix ID : Disks Selected : 240 Director : DF-7A Interface : C Target ID : C Disk Group Number : 1 Vendor ID Product ID Product Revision Serial ID : SATAHGST : KLCLAR1000 : N01THGK : PAHR1Y5F Disk Blocks : Block Size : 520 Actual Disk Blocks : Total Disk Capacity (MB) : Free Disk Capacity (MB) : Actual Disk Capacity (MB) : Hot Spare : False Failed Disk : False Hypers (10): { # Vol Emulation Dev Type Mir Mbr Status Cap(MB)

23 Virtual LUN migrations - - N/A - GAP - - N/A FBA 005C RAID Ready FBA 00D0 RAID Ready FBA 097C RAID Ready FBA 090B RAID Ready FBA 0925 RAID Ready FBA 0961 RAID Ready FBA 0954 RAID Ready N/A - GAP - - N/A FBA 0988 RAID Ready FBA 0ACF RAID Ready FBA 0AE9 RAID Ready N/A - GAP - - N/A } Director : DF-7A Interface : C Target ID : E Disk Group Number : 1 Vendor ID Product ID Product Revision Serial ID : SATAHGST : KLCLAR1000 : N01THGK : PAHPTD4E Disk Blocks : Block Size : 520 Actual Disk Blocks : Total Disk Capacity (MB) : Free Disk Capacity (MB) : Actual Disk Capacity (MB) : Hot Spare : False Failed Disk : False Hypers (10): { # Vol Emulation Dev Type Mir Mbr Status Cap(MB) N/A - GAP - - N/A FBA 006C RAID Ready FBA 00E0 RAID Ready FBA 0907 RAID Ready N/A - GAP - - N/A FBA 0923 RAID Ready FBA 0946 RAID Ready FBA 096E Data 1 1 Ready FBA 0982 RAID Ready FBA 098B RAID Ready FBA 0AD1 RAID Ready FBA 0AEB RAID Ready N/A - GAP - - N/A }... Using SMC, the disk group information can also be viewed. In Figure 15, diskgroup 1 is shown to contain SATA drives. To the right-hand side of 23

24 Virtual LUN migrations the properties, a pie chart graph is shown illustrating used capacity and freespace in the diskgroup. By clicking the Data Disks tab, the list of physical drives in the group is displayed as shown in the insert. Figure 15 Diskgroup properties displayed in SMC Configured space When migrating to configured space, the target devices used in the migration must be unallocated. The devices must not be accessible by any host, that is, unmapped and/or unmasked. Solutions Enabler 7.0 introduces a new filtering option, -migr_tgt, to the symdev list command to display all potential target devices of the required RAID protection type, capacity, and in the correct disk group. To display all unallocated devices in a particular disk group, run: symdev list sid 1254 disk_group 1 migr_tgt 24

25 Virtual LUN migrations Symmetrix ID: Device Name Directors Device Cap Sym Physical SA :P DA :IT Config Attribute Sts (MB) Not Visible???:? 07A:CE RAID-5 N/Grp'd RW Not Visible???:? 08B:CE RAID-5 N/Grp'd RW Not Visible???:? 08A:CD RAID-5 N/Grp'd RW A Not Visible???:? 07B:CD RAID-5 N/Grp'd RW B Not Visible???:? 07A:CC RAID-5 N/Grp'd RW C Not Visible???:? 08A:DC RAID-5 N/Grp'd RW B Not Visible???:? 08C:CB 2-Way Mir N/Grp'd RW C Not Visible???:? 07D:CB 2-Way Mir N/Grp'd RW C Not Visible???:? 07A:DD BCV N/Asst'd RW D Not Visible???:? 08B:DD BCV N/Asst'd RW E Not Visible???:? 07A:CE BCV N/Asst'd RW F Not Visible???:? 09A:CE BCV N/Asst'd RW Not Visible???:? 08C:DE BCV N/Asst'd RW Not Visible???:? 10C:DE BCV N/Asst'd RW Not Visible???:? 08B:CE BCV N/Asst'd RW Not Visible???:? 10B:CE BCV N/Asst'd RW Not Visible???:? 07D:DE BCV N/Asst'd RW Not Visible???:? 09D:DE BCV N/Asst'd RW ACC Not Visible???:? 08A:DC RAID-5 N/Grp'd RW ACD Not Visible???:? 08A:CD RAID-5 N/Grp'd RW ACE Not Visible???:? 07A:DB RAID-5 N/Grp'd RW ACF Not Visible???:? 07A:CC RAID-5 N/Grp'd RW AD0 Not Visible???:? 08A:CB RAID-5 N/Grp'd RW AD1 Not Visible???:? 07A:CE RAID-5 N/Grp'd RW AE6 Not Visible???:? 08A:DC RAID-5 N/Grp'd RW AE7 Not Visible???:? 08A:CD RAID-5 N/Grp'd RW AE8 Not Visible???:? 07A:DB RAID-5 N/Grp'd RW AE9 Not Visible???:? 07A:CC RAID-5 N/Grp'd RW AEA Not Visible???:? 08A:CB RAID-5 N/Grp'd RW AEB Not Visible???:? 07A:CE RAID-5 N/Grp'd RW 8631 To display all unallocated devices of a particular RAID protection type in the same disk group, and that are 8631 MB in size, run: symdev list sid 1254 disk_group1 raid5 protection 7+1 cap 8631 migr_tgt Symmetrix ID: Device Name Directors Device Cap Sym Physical SA :P DA :IT Config Attribute Sts (MB) ACC Not Visible???:? 08A:DC RAID-5 N/Grp'd RW ACD Not Visible???:? 08A:CD RAID-5 N/Grp'd RW ACE Not Visible???:? 07A:DB RAID-5 N/Grp'd RW

26 Virtual LUN migrations 0ACF Not Visible???:? 07A:CC RAID-5 N/Grp'd RW AD0 Not Visible???:? 08A:CB RAID-5 N/Grp'd RW AD1 Not Visible???:? 07A:CE RAID-5 N/Grp'd RW AE6 Not Visible???:? 08A:DC RAID-5 N/Grp'd RW AE7 Not Visible???:? 08A:CD RAID-5 N/Grp'd RW AE8 Not Visible???:? 07A:DB RAID-5 N/Grp'd RW AE9 Not Visible???:? 07A:CC RAID-5 N/Grp'd RW AEA Not Visible???:? 08A:CB RAID-5 N/Grp'd RW AEB Not Visible???:? 07A:CE RAID-5 N/Grp'd RW 8631 Configured space can also be viewed in SMC, by selecting the Devices folder in the navigation pane, and then selecting the appropriate protection, as shown in Figure 16. Figure 16 Unmapped RAID 5 devices Devices can be sorted by capacity or emulation by clicking on the appropriate column header. 26

27 Management interface: SYMCLI Management interface: SYMCLI Solutions Enabler 7.0 introduced a new SYMCLI command, symmigrate. The symmigrate command has three control actions and three monitor actions. The control actions are: validate Tests the user input to see if it would succeed at the current point in time, optionally generate a device pair file establish Creates the migration session and will start the synchronization process. terminate Removes a specific session by session name. The monitor actions are: query Provides status about a specific session by session name. list Shows all sessions for a given Symmetrix or all local Symmetrix arrays. verify Determines if a specific session by session name is in a specified state. Validate There are two uses for the symmigrate validate command. The first use is the ability to perform a positive/negative test to determine whether a migration will succeed. Secondly, the command can be used to generate a device file containing exact pairings of source and target devices that can be used with the symmigrate establish command when performing a migration to configured space. The target volumes included in the output file are automatically selected by Enginuity as being the most suitable targets for the source volumes to be migrated to. Examples: Device group symmigrate name mig_01 g app01 tgt_configured tgt_dsk_grp 3 tgt_raid5 tgt_prot 7+1 validate outfile dev_pairs.txt -v 'Validate' operation execution is in progress for the device group 'migrate_rdf'. Please wait... STARTING a Migrate 'VALIDATE' operation. SELECTING the list of Source devices: 27

28 Management interface: SYMCLI Devices: 0790, 0791, 0792, 0793 [SELECTED] Validate Migration...Started. Validate Migration...Done. The Migrate 'VALIDATE' operation SUCCEEDED. 'Validate' operation successfully executed for the device group 'migrate_rdf'. cat dev_pairs.txt c cb a a Storage group symmigrate name mig_01 sid 1254 sg host01 -tgt_configured tgt_dsk_grp 3 tgt_raid5 tgt_prot 7+1 validate outfile dev_pairs.txt -v 'Validate' operation execution is in progress for the device group 'LICOA067_RDF'. Please wait... STARTING a Migrate 'VALIDATE' operation. SELECTING the list of Source devices: Devices: 0790, 0791, 0792, 0793 [SELECTED] Validate Migration...Started. Validate Migration...Done. The Migrate 'VALIDATE' operation SUCCEEDED. 'Validate' operation successfully executed for the device group 'LICOA067_RDF'. cat dev_pairs.txt c cb a a Device pairs file symmigrate name mig_01 sid 1254 f dev_pairs.txt validate -v 'Validate' operation execution is in progress for the device list in device file 'devs1.txt'. Please wait... STARTING a Migrate 'VALIDATE' operation. PAIRING of Source and Target Devices: Devices: C6, CB, A5, A 28

29 Management interface: SYMCLI Validate Migration...Started. Validate Migration...Done. The Migrate 'VALIDATE' operation SUCCEEDED. 'Validate' operation successfully executed for the device list in device file 'devs1.txt'. Note: The file output is only a listing of what the system chose to do at the time the validate command was run. To guarantee that the exact pairs that were returned are used, run the symmigrate establish command with the file that was output by the validate command. Establish The symmigrate establish command creates the migration session and begins the migration of the source devices to the new target location. The target protection type and disk group number must be provided by the user, unless a device pair file is used. This is the point in the migration process that the mirrors are moved to the source device from the target, if using configured space, or are created if using unconfigured space. The establish command will return control to the command prompt after the first configuration change to attach the secondary RAID group to the source has completed. An In Progress status will be reported on the screen every 60 seconds to indicate that the command is still running and that the session status is CreateInProg. Once completed, the migration session status will be SyncInProg. Examples: Device group symmigrate name mig_01 g app01 tgt_configured tgt_dsk_grp 3 tgt_raid5 tgt_prot 7+1 establish -v Storage group symmigrate name mig_01 sid 1254 sg host01 -tgt_configured tgt_dsk_grp 3 tgt_raid5 tgt_prot 7+1 establish -v Device pairs file symmigrate name mig_01 sid 1254 f dev_pairs.txt establish v 'Establish' operation execution is in progress for the device list in device file 'devs1.txt'. Please wait... STARTING a Migrate 'ESTABLISH' operation. PAIRING of Source and Target Devices: 29

30 Management interface: SYMCLI Devices: C6, CB, A5, A Establish Migration...Started. Establish Migration...In Progress. Establish Migration...In Progress. Establish Migration...In Progress. Establish Migration...Done. The Migrate 'ESTABLISH' operation SUCCEEDED. 'Establish' operation successfully executed for the device list in device file 'devs1.txt'. Terminate The symmigrate terminate command is used to acknowledge the successful completion of the migration, and to clear the session information from the Symmetrix. The terminate action can only be performed when all devices in the session are in a Migrated state. Example: symmigrate name mig_01 sid 1254 terminate 'Terminate' operation execution is in progress for the session named 'mig_01'. Please wait... Terminate Migration...Started. Terminate Migration...Done. 'Terminate' operation successfully executed for the session named 'mig_01'. Query The symmigrate query command returns information on all the devices being migrated within a specified migration session. The command can be run with the detail option to provide more information about the migration, including target disk group and target RAID protection. The command can also be used with the optional i (interval) flag to specify a repeat interval, in seconds, at which to run the query automatically. Following the second iteration of the query, the output returned will include an estimated time to completion for the data synchronization portion of the migration, along with the data transfer rate for the previous interval. Example: symmigrate name mig_01 sid 1254 query detail i 30 Symmetrix ID:

31 Management interface: SYMCLI Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 N/A SyncInProg RAID-5(7+1) mig_01 0BE9 N/A SyncInProg RAID-5(7+1) mig_01 0BEA N/A SyncInProg 9 01 RAID-5(7+1) mig_01 0BEB N/A SyncInProg RAID-5(7+1) mig_01 0BEC N/A SyncInProg RAID-5(7+1) mig_01 0BF0 N/A SyncInProg RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 13 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 N/A SyncInProg RAID-5(7+1) mig_01 0BE9 N/A SyncInProg RAID-5(7+1) mig_01 0BEA N/A SyncInProg RAID-5(7+1) mig_01 0BEB N/A SyncInProg RAID-5(7+1) mig_01 0BEC N/A SyncInProg RAID-5(7+1) mig_01 0BF0 N/A SyncInProg RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 21 Copy rate : MB/S Estimated time to completion : 00:05:43 List The symmigrate list command lists all migration sessions for a given Symmetrix, or for all locally attached Symmetrix storage arrays. Used with the optional detail flag, information on the status of the session and percent complete for each device being migrated, as well as the target disk group and target protection, will be displayed. Alternatively, the names options can added to display a single line summary for each migration session in the Symmetrix. Examples: symmigrate sid 1254 list -detail Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name 31

32 Management interface: SYMCLI N/A 0 Migrated RAID-1 mig_proddb 0791 N/A 0 Migrated RAID-1 mig_proddb 0792 N/A 0 Migrated RAID-1 mig_proddb 0793 N/A 0 Migrated RAID-1 mig_proddb 0BE8 0AE SyncInProg RAID-5(7+1) mig_01 0BE9 0AE SyncInProg RAID-5(7+1) mig_01 0BEA 0C SyncInProg RAID-5(7+1) mig_01 0BEB 0C SyncInProg RAID-5(7+1) mig_01 0BEC 0AD SyncInProg RAID-5(7+1) mig_01 0AD1 - SyncInProg RAID-5(7+1) mig_01 0AE8 - SyncInProg RAID-5(7+1) mig_01 0AE6 - SyncInProg RAID-5(7+1) mig_01 0BF0 0ACC SyncInProg RAID-5(7+1) mig_01 0ACE - SyncInProg RAID-5(7+1) mig_01 0ACF - SyncInProg RAID-5(7+1) mig_01 0ACD - SyncInProg RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 39 symmigrate list -detail -names Symmetrix ID: Invalid Status Done Session Name Tracks SRC => TGT () mig_ SyncInProg 29 mig_proddb 0 Migrated 100 Total Tracks MB(s) Done(%) 39 Note: A Tgt value of N/A in the symmigrate query or list outputs indicates that the migration being performed is targeting unconfigured space. Verify The symmigrate verify command verifies whether all the devices in a specified migration session are in the CreateinProg, SyncinProg, Synchronized, MigrateinProg, or Migrated states Similarly to the query command, verify can be run with the optional i (interval) flag to rerun the command at an interval specified in seconds. 32

33 Management interface: SYMCLI When all the devices in the session are in the requested state the command will cease executing. Example: symmigrate name mig_01 sid 1254 verify -migrated All session(s) with name 'mig_01' are in 'Migrated' state. 33

34 Management interface: SMC Management interface: SMC Symmetrix Management Console 7.0 provides several wizards for performing tasks within a Symmetrix environment. One such wizard is the LUN Migration wizard available via the Tasks view, as shown in Figure 17. Figure 17 SMC Tasks view showing the LUN Migration Wizard 34

35 Management interface: SMC When initiated, the LUN Migration wizard will display the welcome screen, providing an overview of what is required to perform the migration (see Figure 18). The information needed is the same as that needed for a migration performed via SYMCLI. Figure 18 SMC LUN Migration Wizard: Welcome 35

36 Management interface: SMC Clicking Next allows for the selection of the devices to be migrated (Figure 19). The Symmetrix serial number and a migration session name are first provided. The source devices are then specified in one of three ways: Manual selection ( Ungrouped ) Device group Storage group Figure 19 SMC LUN Migration Wizard: Select Source Devices 36

37 Management interface: SMC Selecting Ungrouped will populate the Available Devices field. Devices displayed will be any device available for migration that is not part of a device group or a storage group. From this, devices can be highlighted and moved to the Selected Source Devices field using the Add button, as shown in Figure 20. Figure 20 SMC LUN Migration Wizard: Select Source Devices - Ungrouped 37

38 Management interface: SMC Selecting a group type of Device Group will enable the Select button beside the Group Name field. This will display a group selection screen as seen in Figure 21. Figure 21 SMC LUN Migration Wizard: Device Group selection 38

39 Management interface: SMC Once the device group is selected, the Selected Source Devices field is populated with the appropriate devices from the device group, as shown in Figure 22. Figure 22 SMC LUN Migration Wizard: Device Group selected 39

40 Management interface: SMC If the Group Type is set to Storage Group, when the Select button is clicked, all available storage groups in the Symmetrix will be displayed (Figure 23). Figure 23 SMC LUN Migration Wizard: Storage Group selection 40

41 Management interface: SMC When the group is selected, all devices from within the storage group will be displayed in the Selected Source Devices field, as shown in Figure 24. Figure 24 SMC LUN Migration Wizard: Storage Group selected 41

42 Management interface: SMC After the devices to be migrated have been identified, the next step is to choose the type of migration to configured or unconfigured space. Choosing either the Configured devices or UnConfigured devices radio button as the target of the migration will activate the Protection Type and Disk Group fields as shown in Figure 25. Figure 25 SMC LUN Migration Wizard: Target device type selection 42

43 Management interface: SMC Choosing configured devices as the target will produce a list of recommended target devices as shown in Figure 26. Figure 26 SMC LUN Migration Wizard: Recommended configured target devices 43

44 Management interface: SMC The user can either accept the recommended devices, or click the Select Other Target Devices button to manually select target devices. This leads to a list of potential targets being displayed and can be edited by using the Add or Remove buttons as shown in Figure 27. Figure 27 SMC LUN Migration Wizard: Manual target device selection 44

45 Management interface: SMC Once the target devices are selected, click the Next button and a final review screen is displayed (Figure 28). Figure 28 SMC LUN Migration Wizard: Final review From this screen, when the Finish button is clicked the migration is submitted to the array. 45

46 Management interface: SMC After the migration has been submitted to the Symmetrix, its progress can be tracked via the Migration Sessions folder in the SMC Navigation pane (Figure 29). Figure 29 SMC Migration Sessions Note: As SMC does not actively poll the Symmetrix and update status in real time, to display the most recent status, Refresh View must be clicked. 46

47 Management interface: SMC When the migration session has reached the Migrated state it can then be terminated. To do this, the user must right-click on the migration session name under the Migration Sessions folder in the navigation pane. From the resulting menu, select Migration > Terminate Migration Session (Figure 30). Figure 30 Terminating a migration session 47

48 Logging Logging The validate, establish and terminate actions are all logged to both the Symmetrix audit log as well as the symapi-<date>.log file on the host the symmigrate commands were run from. Symmetrix audit log The Symmetrix audit log is available from any locally or remotely connected Solutions Enabler host. A new function class, Migrate, and a new application id, SYMMIGRATE, have been added to allow for filtering of Virtual LUN migration entries within the audit log. To view the contents of the audit log the following command can be run: symaudit list sid 1254 function_class Migrate start_date 02/07/2009 A U D I T L O G D A T A Symmetrix ID : Record Function Action Number Date Time Application Host Class Code /07/09 14:12:04 SYMMIGRATE LICOA067 Migrate Validate /07/09 14:12:04 SYMMIGRATE LICOA067 Migrate Validate /07/09 14:12:04 SYMMIGRATE LICOA067 Migrate Validate /07/09 14:12:04 SYMMIGRATE LICOA067 Migrate Validate /07/09 14:12:10 SYMMIGRATE LICOA067 Migrate Validate /07/09 14:17:20 SYMMIGRATE LICOA067 Migrate FullEsta /07/09 14:17:20 SYMMIGRATE LICOA067 Migrate FullEsta /07/09 14:17:20 SYMMIGRATE LICOA067 Migrate FullEsta /07/09 14:17:20 SYMMIGRATE LICOA067 Migrate FullEsta /07/09 14:18:23 SWPROC Migrate Migrate /07/09 14:18:21 SWPROC Migrate Migrate /07/09 14:19:02 SYMMIGRATE LICOA067 Migrate FullEsta /07/09 14:28:05 SWPROC Migrate Migrate /07/09 14:28:07 SWPROC Migrate Migrate /07/09 14:30:00 SWPROC Migrate Migrate /07/09 14:29:58 SWPROC Migrate Migrate /07/09 14:30:14 SWPROC Migrate Migrate /07/09 14:30:15 SWPROC Migrate Migrate /07/09 14:57:10 SYMMIGRATE LICOA067 Migrate Terminat /07/09 14:57:10 SYMMIGRATE LICOA067 Migrate Terminat... To view more detailed information on the audit log records detailing the symmigrate establish, run: symaudit list -sid record_num n 1 -v 48

49 Logging A U D I T L O G D A T A Symmetrix ID : Record Number : 8696 Records in Seq : 4 Offset in Seq : 1 Time : 03/07/09 14:17:20 Vendor ID : EMC Corp Application ID : SYMMIGRATE Application Version : API Library : SEK API Version : T (Edit Level: 907) Host Name : LICOA067 OS Name : SunOS OS Revision : 5.10Generi Client Host : Process ID : Task ID : Function Class : Migrate Action Code : FullEstablish Text : STARTING a Migrate 'ESTABLISH' operation for session named "mig_01". Options=(RAID5_7+1, DiskGroup 1, Configured Space, NONE) Username : H:LICOA067\root Activity ID : SE9dd75b332c The detailed audit log entries indicate the target diskgroup, target protection type, and whether the migration was to configured or unconfigured space. Using the Activity ID from the audit log record for the establish, the symaudit command can provide the start and end timestamp for the migration, thereby providing the duration of the migration. symaudit list -sid activityid SE9dd75b332c A U D I T L O G D A T A Symmetrix ID : Record Function Action Number Date Time Application Host Class Code /07/09 14:17:20 SYMMIGRATE LICOA067 Migrate FullEsta /07/09 14:17:20 SYMMIGRATE LICOA067 Migrate FullEsta /07/09 14:17:20 SYMMIGRATE LICOA067 Migrate FullEsta /07/09 14:17:20 SYMMIGRATE LICOA067 Migrate FullEsta /07/09 14:18:23 SWPROC Migrate Migrate /07/09 14:18:21 SWPROC Migrate Migrate /07/09 14:19:02 SYMMIGRATE LICOA067 Migrate FullEsta /07/09 14:28:05 SWPROC Migrate Migrate /07/09 14:28:07 SWPROC Migrate Migrate /07/09 14:30:00 SWPROC Migrate Migrate /07/09 14:29:58 SWPROC Migrate Migrate /07/09 14:30:14 SWPROC Migrate Migrate 49

50 Logging /07/09 14:30:15 SWPROC Migrate Migrate The entries showing an Application of SWPROC log the configuration changes made to create or move the RAID groups during the migration. These same entries can also be seen in the audit log via the SMC interface, as shown in Figures 31 and 32. Figure 31 SMC audit log summary 50

51 Logging Figure 32 SMC audit log record detail SYMAPI log Viewing the symapi-<date>.log file for the same date shows the following: more symapi log 03/07/ :11: STARTING a Migrate 'VALIDATE' operation for session named "mig_01". Options=(RAID5_7+1, DiskGroup 1, Configured Space, NONE) 03/07/ :12: The Migrate 'VALIDATE' operation SUCCESSFULLY COMPLETED. 03/07/ :17: STARTING a Migrate 'ESTABLISH' operation for session named "mig_01". Options=(RAID5_7+1, DiskGroup 1, Configured Space, NONE) 03/07/ :18: EMC:SYMMIGRATE process_load_request Switching to FULL load for because the configuration changed (new chksum: B7 old: C24CFE49) 03/07/ :18: EMC:SYMMIGRATE process_load_request Switching to FULL load for because the configuration changed (new chksum: B7 old: C24CFE49) 03/07/ :18: The Migrate 'ESTABLISH' operation SUCCESSFULLY 51

52 Logging COMPLETED. 03/07/ :57: STARTING a Migrate 'TERMINATE' operation for session named "mig_01". Options=(No target information available, NONE) 03/07/ :57: The Migrate 'TERMINATE' operation SUCCESSFULLY COMPLETED. Note: The symapi-<date>.log file is typically located in the /var/symapi/log directory on UNIX systems, and in \Program Files\EMC\symapi\log on Windows. 52

53 Operational examples symdg show app01 Group Name: app01 The examples in this technical note include the latest Virtual LUN technology at the time of publication, including features new in Enginuity 5874, SMC 7.0, and Solutions Enabler 7.0. In all examples, the same six SRDF R1 devices, in Symmetrix , will be migrated from RAID 1 protection on Fibre Channel drives to RAID protection on SATA drives. Of the six SRDF devices, four are 8630 MB in size, while two are four-member metadevices comprised of 8631 MB members. Note: In the following examples, outputs containing an ellipsis ( ) indicates that output, not affecting the example, has been removed. The R1 devices are contained in a Solutions Enabler device group app01. Group Type : RDF1 (RDFA) Device Group in GNS : Yes Valid : Yes Symmetrix ID : Group Creation Time : Tue Mar 3 15:28: Vendor ID : EMC Corp Application ID : SYMCLI Number of STD Devices in Group : 6 Number of Associated GK's : 0 Number of Locally-associated BCV's : 6 Number of Locally-associated VDEV's : 0 Number of Locally-associated TGT's : 0 Number of Remotely-associated VDEV's(STD RDF): 0 Number of Remotely-associated BCV's (STD RDF): 0 Number of Remotely-associated TGT's(TGT RDF) : 0 Number of Remotely-associated BCV's (BCV RDF): 0 Number of Remotely-assoc'd RBCV's (RBCV RDF) : 0 Number of Remotely-assoc'd BCV's (Hop-2 BCV) : 0 Number of Remotely-assoc'd VDEV's(Hop-2 VDEV): 0 Number of Remotely-assoc'd TGT's (Hop-2 TGT) : 0 Standard (STD) Devices (6): { Sym Cap LdevName PdevName Dev Att. Sts (MB) DEV001 /dev/rdsk/emcpower35c 0BE8 RW 8631 DEV002 /dev/rdsk/emcpower34c 0BE9 RW 8631 DEV003 /dev/rdsk/emcpower33c 0BEA RW 8631 DEV004 /dev/rdsk/emcpower32c 0BEB RW

54 DEV005 /dev/rdsk/emcpower31c 0BEC (M) RW DEV006 /dev/rdsk/emcpower30c 0BF0 (M) RW } BCV Devices Locally-associated (6): { Sym Cap LdevName PdevName Dev Att. Sts (MB) BCV001 N/A 0BF4 RW 8631 BCV002 N/A 0BF5 RW 8631 BCV003 N/A 0BF6 RW 8631 BCV004 N/A 0BF7 RW 8631 BCV005 N/A 0BF8 (M) RW BCV006 N/A 0BFC (M) RW }... symclone -g app01 query The devices are replicated locally to a set of six BCVs using TimeFinder/Clone. Device Group (DG) Name: app01 DG's Type : RDF1 DG's Symmetrix ID : Source Device Target Device State Copy Protected Modified Modified Logical Sym Tracks Tracks Logical Sym Tracks CGDP SRC <=> TGT (%) DEV001 0BE8 0 0 BCV001 0BF4 0 XXX. Copied 100 DEV002 0BE9 0 0 BCV002 0BF5 0 XXX. Copied 100 DEV003 0BEA 0 0 BCV003 0BF6 0 XXX. Copied 100 DEV004 0BEB 0 0 BCV004 0BF7 0 XXX. Copied 100 DEV005 0BEC 0 0 BCV005 0BF8 0 XXX. Copied 100 DEV006 0BF0 0 0 BCV006 0BFC 0 XXX. Copied 100 Total Track(s) MB(s) Legend: (C): X = The background copy setting is active for this pair.. = The background copy setting is not active for this pair. (G): X = The Target device is associated with this group.. = The Target device is not associated with this group. (D): X = The Clone session is a differential copy session.. = The Clone session is not a differential copy session. (P): X = The pre-copy operation has completed one cycle. = The pre-copy operation has not completed one cycle 54

55 The devices are also replicated remotely to Symmetrix by SRDF in Asynchronous mode. symrdf -g app01 query -rdfa Device Group (DG) Name : app01 DG's Type : RDF1 DG's Symmetrix ID : (Microcode Version: 5874) RDFA Session Number : 11 RDFA Cycle Number : 8936 RDFA Session Status : Active RDFA Consistency Exempt Devices : No RDFA Minimum Cycle Time : 00:00:30 RDFA Avg Cycle Time : 00:00:30 Duration of Last cycle : 00:00:30 RDFA Session Priority : 33 Tracks not Committed to the R2 Side: 0 Time that R2 is behind R1 : 00:00:40 R2 Image Capture Time : Sat Mar 7 13:03: R2 Data is Consistent : True RDFA R1 Side Percent Cache In Use : 0 RDFA R2 Side Percent Cache In Use : 0 R1 Side DSE Used Tracks : 0 R2 Side DSE Used Tracks : 0 Transmit Idle Time : 00:00:00 Remote Symmetrix ID : (Microcode Version: 5874) RDF (RA) Group Number : 12 (0B) Source (R1) View Target (R2) View MODES ST LI ST Standard A N A Logical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF Pair Device Dev E Tracks Tracks S Dev E Tracks Tracks MDACE STATE DEV001 0BE8 RW 0 0 RW 1640 WD 0 0 A... Consistent DEV002 0BE9 RW 0 0 RW 1641 WD 0 0 A... Consistent DEV003 0BEA RW 0 0 RW 1642 WD 0 0 A... Consistent DEV004 0BEB RW 0 0 RW 1643 WD 0 0 A... Consistent DEV005 0BEC RW 0 0 RW 1644 WD 0 0 A... Consistent DEV006 0BF0 RW 0 0 RW 1648 WD 0 0 A... Consistent Total Track(s) MB(s) Legend for MODES: M(ode of Operation) : A = Async, S = Sync, E = Semi-sync, C = Adaptive Copy D(omino) : X = Enabled,. = Disabled A(daptive Copy) : D = Disk Mode, W = WP Mode,. = ACp off C(onsistency State) : X = Enabled,. = Disabled, M = Mixed, - = N/A (Consistency) E(xempt): X = Enabled,. = Disabled, M = Mixed, - = N/A 55

56 Migration to unconfigured space using SYMCLI In this example, the six R1 devices will be migrated to unconfigured space on SATA drives. To determine which diskgroup to perform the migration to, the symdisk command can be used to list all physical drives in the array sorted by diskgroup. In the following output, diskgroup 0 contains 300 GB (15,000 rpm) Fibre Channel drives, while diskgroup 1 contains 1 TB (7,200 rpm) SATA drives. symdisk list -by_diskgroup -sid 54 Symmetrix ID : Disks Selected : 240 Capacity(MB) Ident Symb Int TID Vendor Type Hypers Total Free Actual Disk Group 0: DF-7A 07A C 0 SEAGATE T DF-7A 07A C 2 SEAGATE T DF-7A 07A C 4 SEAGATE T DF-7A 07A C 6 SEAGATE T DF-7A 07A C 8 SEAGATE T DF-10D 10D D 1 SEAGATE T DF-10D 10D D 3 SEAGATE T DF-10D 10D D 5 SEAGATE T DF-10D 10D D 7 SEAGATE T DF-10D 10D D 9 SEAGATE T DF-10D 10D D B SEAGATE T Disk Group 1: DF-7A 07A C C SATAHGST N01THGK DF-7A 07A C E SATAHGST N01THGK DF-7A 07A D B SATAHGST N01THGK DF-7A 07A D D SATAHGST N01THGK DF-9D 09D D C SATAHGST N01THGK DF-9D 09D D E SATAHGST N01THGK DF-10D 10D C C SATAHGST N01THGK DF-10D 10D D D SATAHGST N01THGK The symdisk command can then be used to list the proposed target diskgroup (in this case diskgroup 1) to determine if there is sufficient freespace in the diskgroup, and sufficient DAs and physical drives to support RAID devices. symdisk list -sid 54 -disk_group 1 Symmetrix ID :

57 Disks Selected : 56 Capacity(MB) Ident Symb Int TID Vendor Type Hypers Total Free Actual DF-7A 07A C C SATAHGST N01THGK DF-7A 07A C E SATAHGST N01THGK DF-7A 07A D B SATAHGST N01THGK DF-7A 07A D D SATAHGST N01THGK DF-8A 08A C B SATAHGST N01THGK DF-8A 08A C D SATAHGST N01THGK DF-8A 08A D C SATAHGST N01THGK DF-8A 08A D E SATAHGST N01THGK DF-9A 09A C C SATAHGST N01THGK DF-9A 09A C E SATAHGST N01THGK DF-9A 09A D D SATAHGST N01THGK DF-10A 10A C B SATAHGST N01THGK DF-10A 10A C D SATAHGST N01THGK DF-10A 10A D C SATAHGST N01THGK DF-10A 10A D E SATAHGST N01THGK DF-7B 07B C B SATAHGST N01THGK DF-7B 07B C D SATAHGST N01THGK DF-7B 07B D C SATAHGST N01THGK DF-7B 07B D E SATAHGST N01THGK DF-8B 08B C C SATAHGST N01THGK DF-8B 08B C E SATAHGST N01THGK DF-8B 08B D B SATAHGST N01THGK DF-8B 08B D D SATAHGST N01THGK DF-9B 09B C B SATAHGST N01THGK DF-9B 09B C D SATAHGST N01THGK DF-9B 09B D C SATAHGST N01THGK DF-9B 09B D E SATAHGST N01THGK DF-10B 10B C C SATAHGST N01THGK DF-10B 10B C E SATAHGST N01THGK DF-10B 10B D D SATAHGST N01THGK DF-7C 07C C C SATAHGST N01THGK DF-7C 07C D B SATAHGST N01THGK DF-7C 07C D D SATAHGST N01THGK DF-8C 08C C B SATAHGST N01THGK DF-8C 08C C D SATAHGST N01THGK DF-8C 08C D C SATAHGST N01THGK DF-8C 08C D E SATAHGST N01THGK DF-9C 09C C C SATAHGST N01THGK DF-9C 09C D D SATAHGST N01THGK DF-10C 10C C B SATAHGST N01THGK DF-10C 10C C D SATAHGST N01THGK DF-10C 10C D C SATAHGST N01THGK DF-10C 10C D E SATAHGST N01THGK DF-7D 07D C B SATAHGST N01THGK DF-7D 07D C D SATAHGST N01THGK DF-7D 07D D C SATAHGST N01THGK DF-7D 07D D E SATAHGST N01THGK DF-8D 08D C C SATAHGST N01THGK DF-8D 08D D B SATAHGST N01THGK DF-8D 08D D D SATAHGST N01THGK DF-9D 09D C B SATAHGST N01THGK DF-9D 09D C D SATAHGST N01THGK DF-9D 09D D C SATAHGST N01THGK DF-9D 09D D E SATAHGST N01THGK DF-10D 10D C C SATAHGST N01THGK DF-10D 10D D D SATAHGST N01THGK

58 symdev show be8 -sid 54 Prior to migrating the device, the output of the symdev show command of one of the devices shows that the device is locally protected by a single RAID 1 primary RAID group, configured in diskgroup 0, as well as remotely protected. Device Physical Name : /dev/rdsk/emcpower35c Device Symmetrix Name : 0BE8 Device Serial ID : 5400BE8000 Symmetrix ID : Device Group Name Device Logical Name : app01 : DEV001 Number of RAID Groups : 1... Device Configuration : RDF1+Mir... Device Status : Ready (RW) Device SA Status : Ready (RW) Front Director Paths (3): { POWERPATH DIRECTOR PORT LUN PdevName Type Type Num Sts VBUS TID SYMM Host /dev/rdsk/emcpower35c PARENT FA 07E:0 RW B3 000 c1t d1s2 CHILD FA 07E:0 RW B3 000 c2t d1s2 CHILD FA 07F:1 RW } Mirror Set Type Mirror Set DA Status : [RAID-1,R2 Remote,N/A,N/A] : [RW,RW,N/A,N/A] Mirror Set Inv. Tracks : [0,0,0,0] Back End Disk Director Information { Hyper Type : RAID-1 Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 1 Hyper Type : R2 Remote Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] 58

59 Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 2 } RAID Group Information { Mirror Number : 1 RAID Type : RAID-1 Device Position : Primary Protection Level : 2 RAID Group Service State : Normal Failing Member Mask : N/A Hyper Devices: { Device : 0BE8 { Disk DA Hyper Member Disk DA :IT Vol# Num Cap(MB) Num Status Grp# Cap(MB) A:D RW A:D RW } } }... Once the devices to be migrated, and the diskgroup to be migrated to, have been identified, along with the desired protection type, the migration can be submitted to the array. First, the symmigrate validate command is used to test the potential success of the migration. In this example, the migration session name being used is mig_01. symmigrate -name mig_01 -g app01 -tgt_dsk_grp 1 -tgt_raid5 -tgt_prot 7+1 -tgt_unconfig validate -v -nop 'Validate' operation execution is in progress for the device group 'app01'. Please wait... STARTING a Migrate 'VALIDATE' operation. SELECTING the list of Source devices: Devices: 0BE8, 0BE9, 0BEA, 0BEB, 0BEC, 0BED, 0BEE, 0BEF, 0BF0, 0BF1, 0BF2, 0BF3 [SELECTED] Validate Migration...Started. Validate Migration...Done. The Migrate 'VALIDATE' operation SUCCEEDED. 'Validate' operation successfully executed for the device group 'app01'. 59

60 When the proposed migration has been validated successfully it can then be established, thereby executing the migration. symmigrate -name mig_01 -g app01 -tgt_dsk_grp 1 -tgt_raid5 -tgt_prot 7+1 -tgt_unconfig est -v -nop 'Establish' operation execution is in progress for the device group 'app01'. Please wait... STARTING a Migrate 'ESTABLISH' operation. SELECTING the list of Source devices: Devices: 0BE8, 0BE9, 0BEA, 0BEB, 0BEC, 0BED, 0BEE, 0BEF, 0BF0, 0BF1, 0BF2, 0BF3 [SELECTED] Establish Migration...Started. Establish Migration...In Progress. Establish Migration...In Progress. Establish Migration...Done. The Migrate 'ESTABLISH' operation SUCCEEDED. 'Establish' operation successfully executed for the device group 'app01'. An initial query of the migration shows the migration session state as being SyncInProg. symmigrate sid 54 name mig_01 query detail Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 N/A SyncInProg 5 01 RAID-5(7+1) mig_01 0BE9 N/A SyncInProg 8 01 RAID-5(7+1) mig_01 0BEA N/A SyncInProg 0 01 RAID-5(7+1) mig_01 0BEB N/A SyncInProg 5 01 RAID-5(7+1) mig_01 0BEC N/A SyncInProg 5 01 RAID-5(7+1) mig_01 0BF0 N/A SyncInProg 7 01 RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 5 While the devices are migrating it is possible to use them in normal replication functions, such as TimeFinder/Clone. Here, a symclone recreate command is run, with precopy, as the migration data transfer process continues. 60

61 symclone -g app01 recreate precopy -nop 'Recreate' operation execution is in progress for device group 'app01'. Please wait... 'Recreate' operation successfully initiated for device group 'app01'. symclone -g app01 query A symclone query of the devices shows that the recreate was successful. Device Group (DG) Name: app01 DG's Type : RDF1 DG's Symmetrix ID : Source Device Target Device State Copy Protected Modified Modified Logical Sym Tracks Tracks Logical Sym Tracks CGDP SRC <=> TGT (%) DEV001 0BE8 0 0 BCV001 0BF4 0 XXXX PreCopy 100 DEV002 0BE9 0 0 BCV002 0BF5 0 XXXX PreCopy 100 DEV003 0BEA 0 0 BCV003 0BF6 0 XXXX PreCopy 100 DEV004 0BEB 0 0 BCV004 0BF7 0 XXXX PreCopy 100 DEV005 0BEC 0 0 BCV005 0BF8 0 XXXX PreCopy 100 DEV006 0BF0 0 0 BCV006 0BFC 0 XXXX PreCopy 100 Total Track(s) MB(s) Legend: (C): X = The background copy setting is active for this pair.. = The background copy setting is not active for this pair. (G): X = The Target device is associated with this group.. = The Target device is not associated with this group. (D): X = The Clone session is a differential copy session.. = The Clone session is not a differential copy session. (P): X = The pre-copy operation has completed one cycle. = The pre-copy operation has not completed one cycle The Clone session can also be activated during the Virtual LUN migration. symclone -g app01 activate -v -nop 'Activate' operation execution is in progress for device group 'app01'. Please wait... 61

62 'Activate' operation successfully executed for device group 'app01'. symclone -g app01 query Device Group (DG) Name: app01 DG's Type : RDF1 DG's Symmetrix ID : Source Device Target Device State Copy Protected Modified Modified Logical Sym Tracks Tracks Logical Sym Tracks CGDP SRC <=> TGT (%) DEV001 0BE8 0 0 BCV001 0BF4 0 XXX. Copied 100 DEV002 0BE9 0 0 BCV002 0BF5 0 XXX. Copied 100 DEV003 0BEA 0 0 BCV003 0BF6 0 XXX. Copied 100 DEV004 0BEB 0 0 BCV004 0BF7 0 XXX. Copied 100 DEV005 0BEC 0 0 BCV005 0BF8 0 XXX. Copied 100 DEV006 0BF0 0 0 BCV006 0BFC 0 XXX. Copied 100 Total Track(s) MB(s) Legend: (C): X = The background copy setting is active for this pair.. = The background copy setting is not active for this pair. (G): X = The Target device is associated with this group.. = The Target device is not associated with this group. (D): X = The Clone session is a differential copy session.. = The Clone session is not a differential copy session. (P): X = The pre-copy operation has completed one cycle. = The pre-copy operation has not completed one cycle The symmigrate query command, when used with the i interval options, allows for the query to be run automatically at the given interval (in seconds). After the second iteration of the query an estimated time to completion is included with the output, along with the current data transfer rate. symmigrate sid 54 name mig_01 query detail i 30 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 N/A SyncInProg RAID-5(7+1) mig_01 62

63 0BE9 N/A SyncInProg RAID-5(7+1) mig_01 0BEA N/A SyncInProg 9 01 RAID-5(7+1) mig_01 0BEB N/A SyncInProg RAID-5(7+1) mig_01 0BEC N/A SyncInProg RAID-5(7+1) mig_01 0BF0 N/A SyncInProg RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 13 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 N/A SyncInProg RAID-5(7+1) mig_01 0BE9 N/A SyncInProg RAID-5(7+1) mig_01 0BEA N/A SyncInProg RAID-5(7+1) mig_01 0BEB N/A SyncInProg RAID-5(7+1) mig_01 0BEC N/A SyncInProg RAID-5(7+1) mig_01 0BF0 N/A SyncInProg RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 21 Copy rate : MB/S Estimated time to completion : 00:05:43 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 N/A SyncInProg RAID-5(7+1) mig_01 0BE9 N/A SyncInProg RAID-5(7+1) mig_01 0BEA N/A SyncInProg RAID-5(7+1) mig_01 0BEB N/A SyncInProg RAID-5(7+1) mig_01 0BEC N/A SyncInProg RAID-5(7+1) mig_01 0BF0 N/A SyncInProg RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 29 Copy rate : MB/S Estimated time to completion : 00:05:06 While the migration is in the SyncInProg state, the output of a symdev show command shows the device being migrated as now being locally protected by two separate RAID groups the primary RAID 1 group which the device started with, and a secondary RAID 5 group to which 63

64 the device is being migrated. The secondary RAID group can be seen to belong to diskgroup 1, while the primary RAID group belongs to diskgroup 0. # symdev show be8 -sid 54 Device Physical Name : /dev/rdsk/emcpower35c Device Symmetrix Name : 0BE8 Device Serial ID : 5400BE8000 Symmetrix ID : Device Group Name Device Logical Name : app01 : DEV001 Number of RAID Groups : 2... Device Configuration Device Service State : RDF1+Mir : Normal Device Status : Ready (RW) Device SA Status : Ready (RW) Front Director Paths (3): { POWERPATH DIRECTOR PORT LUN PdevName Type Type Num Sts VBUS TID SYMM Host /dev/rdsk/emcpower35c PARENT FA 07E:0 RW B3 000 c1t d1s2 CHILD FA 07E:0 RW B3 000 c2t d1s2 CHILD FA 07F:1 RW } Mirror Set Type Mirror Set DA Status : [RAID-1,R2 Remote,RAID-5,N/A] : [RW,RW,RW,N/A] Mirror Set Inv. Tracks : [0,0,102197,0] Back End Disk Director Information { Hyper Type : RAID-1 Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 1 Hyper Type : R2 Remote Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A 64

65 Mirror Number : 2 Hyper Type : RAID-5 Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 3 } RAID Group Information { Mirror Number : 1 RAID Type : RAID-1 Device Position : Primary Protection Level : 2 RAID Group Service State : Normal Failing Member Mask : N/A Hyper Devices: { Device : 0BE8 { Disk DA Hyper Member Disk DA :IT Vol# Num Cap(MB) Num Status Grp# Cap(MB) A:D RW A:D RW } }... Mirror Number : 3 RAID Type : RAID-5 Device Position : Secondary Protection Level : 7+1 RAID Group Service State : Normal Failing Member Mask : N/A Hyper Devices: { Device : 0BE8 { Disk DA Hyper Member Disk DA :IT Vol# Num Cap(MB) Num Status Grp# Cap(MB) C:CC RW A:CC RW A:CC RW D:CC RW D:CC RW B:CC RW B:CC RW C:CC RW } } } 65

66 At the end of the migration, the symmigrate query command will show the session status change from SyncInProg to Synchronized, to MigrInProg, and finally to Migrated. symmigrate sid 54 name mig_01 query detail i 30 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 N/A SyncInProg RAID-5(7+1) mig_01 0BE9 N/A 0 Synchronized RAID-5(7+1) mig_01 0BEA N/A 0 Synchronized RAID-5(7+1) mig_01 0BEB N/A 0 Synchronized RAID-5(7+1) mig_01 0BEC N/A SyncInProg RAID-5(7+1) mig_01 0BF0 N/A SyncInProg RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 97 Copy rate : MB/S Estimated time to completion : 00:00:24 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 N/A 0 Synchronized RAID-5(7+1) mig_01 0BE9 N/A 0 Synchronized RAID-5(7+1) mig_01 0BEA N/A 0 Synchronized RAID-5(7+1) mig_01 0BEB N/A 0 Synchronized RAID-5(7+1) mig_01 0BEC N/A 0 Synchronized RAID-5(7+1) mig_01 0BF0 N/A 0 Synchronized RAID-5(7+1) mig_01 Total Tracks 0 MB(s) 0.0 Done(%) Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 N/A 0 MigrInProg RAID-5(7+1) mig_01 0BE9 N/A 0 MigrInProg RAID-5(7+1) mig_01 0BEA N/A 0 MigrInProg RAID-5(7+1) mig_01 0BEB N/A 0 MigrInProg RAID-5(7+1) mig_01 0BEC N/A 0 MigrInProg RAID-5(7+1) mig_01 0BF0 N/A 0 MigrInProg RAID-5(7+1) mig_01 66

67 Total Tracks 0 MB(s) 0.0 Done(%) 100 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 N/A 0 Migrated RAID-5(7+1) mig_01 0BE9 N/A 0 Migrated RAID-5(7+1) mig_01 0BEA N/A 0 Migrated RAID-5(7+1) mig_01 0BEB N/A 0 Migrated RAID-5(7+1) mig_01 0BEC N/A 0 Migrated RAID-5(7+1) mig_01 0BF0 N/A 0 Migrated RAID-5(7+1) mig_01 Total Tracks 0 MB(s) 0.0 Done(%) 100 Alternatively, the symmigrate verify command can be used to determine if all the devices in a single session have reached the state of Migrated. symmigrate name mig_01 sid 1254 verify -migrated All session(s) with name 'mig_01' are in 'Migrated' state. When the migration session has reached the Migrated status, the symdev show output now shows that the devices migrated are now, once again, protected by a single local RAID group. However, the primary RAID group now is the RAID 5 group located on the SATA drives in diskgroup 1. symdev show be8 -sid 54 Device Physical Name : /dev/rdsk/emcpower35c Device Symmetrix Name : 0BE8 Device Serial ID : 5400BE8000 Symmetrix ID : Device Group Name Device Logical Name : app01 : DEV001 Number of RAID Groups : 1... Device Configuration : RDF1+R-5 67

68 ... Device Service State : Normal Device Status : Ready (RW) Device SA Status : Ready (RW) Front Director Paths (3): { POWERPATH DIRECTOR PORT LUN PdevName Type Type Num Sts VBUS TID SYMM Host /dev/rdsk/emcpower35c PARENT FA 07E:0 RW B3 000 c1t d1s2 CHILD FA 07E:0 RW B3 000 c2t d1s2 CHILD FA 07F:1 RW } Mirror Set Type Mirror Set DA Status : [RAID-5,R2 Remote,N/A,N/A] : [RW,RW,N/A,N/A] Mirror Set Inv. Tracks : [0,0,0,0] Back End Disk Director Information { Hyper Type : RAID-5 Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 1 Hyper Type : R2 Remote Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 2 } RAID Group Information { Mirror Number : 1 RAID Type : RAID-5 Device Position : Primary Protection Level : 7+1 RAID Group Service State : Normal Failing Member Mask : N/A Hyper Devices: { Device : 0BE8 { Disk DA Hyper Member Disk DA :IT Vol# Num Cap(MB) Num Status Grp# Cap(MB) C:CC RW

69 } } 07A:CC RW A:CC RW D:CC RW D:CC RW B:CC RW B:CC RW C:CC RW }... To complete the migration, and to remove the migration session from the Symmetrix, the symmigrate terminate command is run. symmigrate -sid 54 -name mig_01 terminate -v -nop 'Terminate' operation execution is in progress for the session named 'mig_01'. Please wait... STARTING a Migrate 'TERMINATE' operation. SELECTING the list of Source devices: Devices: [SELECTED] Terminate Migration...Started. Terminate Migration...Done. The Migrate 'TERMINATE' operation SUCCEEDED. 'Terminate' operation successfully executed for the session named 'mig_01'. A subsequent query shows the session no longer exists. symmigrate -sid 54 -name mig_01 query Symmetrix ID: The device list with session name 'mig_01' does not have any session information. The Virtual LUN migration is now complete. 69

70 Migration to configured space using SYMCLI In this example, the six R1 devices will be migrated to configured space on SATA drives. To determine which diskgroup to perform the migration to, the symdisk command can be used to list all physical drives in the array sorted by diskgroup. In the following output diskgroup 0 contains 300 GB (15,000 rpm) Fibre Channel drives, while diskgroup 1 contains 1 TB (7,200 rpm) SATA drives. symdisk list -by_diskgroup -sid 54 Symmetrix ID : Disks Selected : 240 Capacity(MB) Ident Symb Int TID Vendor Type Hypers Total Free Actual Disk Group 0: DF-7A 07A C 0 SEAGATE T DF-7A 07A C 2 SEAGATE T DF-7A 07A C 4 SEAGATE T DF-7A 07A C 6 SEAGATE T DF-7A 07A C 8 SEAGATE T DF-10D 10D D 1 SEAGATE T DF-10D 10D D 3 SEAGATE T DF-10D 10D D 5 SEAGATE T DF-10D 10D D 7 SEAGATE T DF-10D 10D D 9 SEAGATE T DF-10D 10D D B SEAGATE T Disk Group 1: DF-7A 07A C C SATAHGST N01THGK DF-7A 07A C E SATAHGST N01THGK DF-7A 07A D B SATAHGST N01THGK DF-7A 07A D D SATAHGST N01THGK DF-9D 09D D C SATAHGST N01THGK DF-9D 09D D E SATAHGST N01THGK DF-10D 10D C C SATAHGST N01THGK DF-10D 10D D D SATAHGST N01THGK Once it has been determined that diskgroup 1 contains the SATA drives, the symdev command can be used to determine if there are sufficient configured devices of the required protection and capacity in the diskgroup. Solutions Enabler 7.0 contains a new migr_tgt option to filter devices that are either unmapped and/or unmasked and so can be used as the target of a migration. 70

71 To list all migration target eligible devices in diskgroup1, of protection level RAID and capacity 8,631 MB, the following command is run: symdev list -disk_group 1 -migr_tgt -emulation fba -raid5 -prot 7+1 -cap 8631 Symmetrix ID: Device Name Directors Device Cap Sym Physical SA :P DA :IT Config Attribute Sts (MB) ACC Not Visible???:? 09D:DC RAID-5 N/Grp'd RW ACD Not Visible???:? 07B:CD RAID-5 N/Grp'd RW ACE Not Visible???:? 08B:DB RAID-5 N/Grp'd RW ACF Not Visible???:? 10B:CC RAID-5 N/Grp'd RW AD0 Not Visible???:? 10A:CB RAID-5 N/Grp'd RW AD1 Not Visible???:? 07A:CE RAID-5 N/Grp'd RW AE6 Not Visible???:? 10A:DC RAID-5 N/Grp'd RW AE7 Not Visible???:? 09B:CD RAID-5 N/Grp'd RW AE8 Not Visible???:? 09A:DD RAID-5 N/Grp'd RW AE9 Not Visible???:? 08B:CC RAID-5 N/Grp'd RW AEA Not Visible???:? 09D:CB RAID-5 N/Grp'd RW AEB Not Visible???:? 09D:DE RAID-5 N/Grp'd RW C00 Not Visible???:? 09C:CC RAID-5 N/Grp'd RW C01 Not Visible???:? 10A:CB RAID-5 N/Grp'd RW C02 Not Visible???:? 10A:DC RAID-5 N/Grp'd RW C03 Not Visible???:? 08B:DB RAID-5 N/Grp'd RW C04 Not Visible???:? 08C:CD RAID-5 N/Grp'd RW C05 Not Visible???:? 07A:CE RAID-5 N/Grp'd RW C06 Not Visible???:? 07C:CC RAID-5 N/Grp'd RW C07 Not Visible???:? 09D:CB RAID-5 N/Grp'd RW C08 Not Visible???:? 08A:DC RAID-5 N/Grp'd RW C09 Not Visible???:? 09A:DD RAID-5 N/Grp'd RW C0A Not Visible???:? 07B:CD RAID-5 N/Grp'd RW C0B Not Visible???:? 09D:DE RAID-5 N/Grp'd RW C0C Not Visible???:? 10B:CC RAID-5 N/Grp'd RW C0D Not Visible???:? 07D:CB RAID-5 N/Grp'd RW C0E Not Visible???:? 10C:DC RAID-5 N/Grp'd RW C0F Not Visible???:? 07A:DB RAID-5 N/Grp'd RW C10 Not Visible???:? 09B:CD RAID-5 N/Grp'd RW C11 Not Visible???:? 07D:DE RAID-5 N/Grp'd RW C12 Not Visible???:? 08B:CC RAID-5 N/Grp'd RW C13 Not Visible???:? 07B:CB RAID-5 N/Grp'd RW C14 Not Visible???:? 08C:DC RAID-5 N/Grp'd RW C15 Not Visible???:? 09C:DD RAID-5 N/Grp'd RW C16 Not Visible???:? 09D:CD RAID-5 N/Grp'd RW C17 Not Visible???:? 10B:CE RAID-5 N/Grp'd RW C18 Not Visible???:? 10D:CC RAID-5 N/Grp'd RW C19 Not Visible???:? 09B:CB RAID-5 N/Grp'd RW C1A Not Visible???:? 09B:DC RAID-5 N/Grp'd RW C1B Not Visible???:? 07C:DB RAID-5 N/Grp'd RW C1C Not Visible???:? 07D:CD RAID-5 N/Grp'd RW C1D Not Visible???:? 08B:CE RAID-5 N/Grp'd RW C1E Not Visible???:? 08D:CC RAID-5 N/Grp'd RW C1F Not Visible???:? 10C:CB RAID-5 N/Grp'd RW C20 Not Visible???:? 07B:DC RAID-5 N/Grp'd RW

72 0C21 Not Visible???:? 10D:DD RAID-5 N/Grp'd RW C22 Not Visible???:? 10A:CD RAID-5 N/Grp'd RW C23 Not Visible???:? 10C:DE RAID-5 N/Grp'd RW 8631 symdev show be8 -sid 54 As can be seen, there is sufficient devices to complete the migration. Prior to migrating the device, the output of the symdev show command against one of the devices shows that the device is locally protected by a single RAID 1 primary RAID group, configured in diskgroup 0, as well as remotely protected. Device Physical Name : /dev/rdsk/emcpower35c Device Symmetrix Name : 0BE8 Device Serial ID : 5400BE8000 Symmetrix ID : Device Group Name Device Logical Name : app01 : DEV001 Number of RAID Groups : 1... Device Configuration : RDF1+Mir... Device Service State : Normal Device Status : Ready (RW) Device SA Status : Ready (RW) Front Director Paths (3): { POWERPATH DIRECTOR PORT LUN PdevName Type Type Num Sts VBUS TID SYMM Host /dev/rdsk/emcpower35c PARENT FA 07E:0 RW B3 000 c1t d1s2 CHILD FA 07E:0 RW B3 000 c2t d1s2 CHILD FA 07F:1 RW } Mirror Set Type Mirror Set DA Status : [RAID-1,R2 Remote,N/A,N/A] : [RW,RW,N/A,N/A] Mirror Set Inv. Tracks : [0,0,0,0] Back End Disk Director Information { Hyper Type : RAID-1 Hyper Status : Ready (RW) 72

73 Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 1 Hyper Type : R2 Remote Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 2 } RAID Group Information { Mirror Number : 1 RAID Type : RAID-1 Device Position : Primary Protection Level : 2 RAID Group Service State : Normal Failing Member Mask : N/A Hyper Devices: { Device : 0BE8 { Disk DA Hyper Member Disk DA :IT Vol# Num Cap(MB) Num Status Grp# Cap(MB) A:D RW A:D RW } } }... Once the devices to be migrated, and the diskgroup to be migrated to, have been identified, along with the desired protection type, the migration can be submitted to the array. First, the symmigrate validate command is used to test the potential success of the migration. The outfile option is also used to generate a device file containing exact device pairs that can be used for the subsequent symmigrate establish. In this example, the migration session name being used is mig_01. symmigrate -name mig_01 -g app01 -tgt_dsk_grp 1 -tgt_raid5 -tgt_prot 7+1 -tgt_config validate -outfile dev_pairs.txt 'Validate' operation execution is in progress for the device group 'app01'. Please wait... STARTING a Migrate 'VALIDATE' operation. SELECTING the list of Source devices: 73

74 Devices: 0BE8, 0BE9, 0BEA, 0BEB, 0BEC, 0BED, 0BEE, 0BEF, 0BF0, 0BF1, 0BF2, 0BF3 [SELECTED] Validate Migration...Started. Validate Migration...Done. The Migrate 'VALIDATE' operation SUCCEEDED. 'Validate' operation successfully executed for the device group 'app01'. cat dev_pairs.txt bec 0ad0,0ad1,0ae8,ae6 bf0 0acc,0ace,acf,0acd beb 0c03 bea 0c02 be9 0ae9 be8 0ae7 The resulting output file contains the recommended device pairings for performing the migration. This file can be used as is, or can be edited as needed. It should be noted that for the metadevices being migrated four individual devices were selected as the target devices. When the proposed migration has been validated successfully it can then be established, thereby executing the migration. Here, the device file generated by the symmigrate validate command is used to specify the devices to be migrated. symmigrate -name mig_01 f dev_pairs.txt sid 54 establish -nop -v 'Establish' operation execution is in progress for the device list in device file 'dev_pairs.txt'. Please wait... STARTING a Migrate 'ESTABLISH' operation. PAIRING of Source and Target Devices: Devices: 0BEC-0AD0, 0BEE-0AD1, 0BED-0AE8, 0BEF-0AE6, 0BF0-0ACC, 0BF1-0ACE, 0BF3-0ACF, 0BF2-0ACD, 0BEB-0C03, 0BEA-0C02, 0BE9-0AE9, 0BE8-0AE7 Establish Migration...Started. Establish Migration...In Progress. Establish Migration...Done. The Migrate 'ESTABLISH' operation SUCCEEDED. 'Establish' operation successfully executed for the device list in device file 'dev_pairs.txt'. 74

75 An initial query of the migration will show the migration session state as being SyncInProg. The query also shows the target device being used for the migration. symmigrate sid 54 name mig_01 query detail Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 0AE SyncInProg 2 01 RAID-5(7+1) mig_01 0BE9 0AE SyncInProg 3 01 RAID-5(7+1) mig_01 0BEA 0C SyncInProg 4 01 RAID-5(7+1) mig_01 0BEB 0C SyncInProg 1 01 RAID-5(7+1) mig_01 0BEC 0AD SyncInProg 2 01 RAID-5(7+1) mig_01 0BF0 0ACC SyncInProg 2 01 RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 2 While the devices are migrating it is possible to use them in normal replication functions, such as SRDF. Here, a symrdf suspend command is run, as the migration data transfer process continues. # symrdf -g app01 suspend -force v -nop An RDF 'Suspend' operation execution is in progress for device group 'app01'. Please wait... RDF Source (R1) group 'app01' STARTING an RDF 'SUSPEND' operation. Scanning device(s) for a 'SELECT ALL DEVS' operation (SOURCE). Device: 0BE8 (Remote Device: 1640) [SELECTED] Device: 0BE9 (Remote Device: 1641) [SELECTED] Device: 0BEA (Remote Device: 1642) [SELECTED] Device: 0BEB (Remote Device: 1643) [SELECTED] Device: 0BEC (Remote Device: 1644) [SELECTED] Device: 0BEE (Remote Device: 1647) [SELECTED] Device: 0BED (Remote Device: 1646) [SELECTED] Device: 0BEF (Remote Device: 1645) [SELECTED] Device: 0BF0 (Remote Device: 1648) [SELECTED] Device: 0BF1 (Remote Device: 164B) [SELECTED] Device: 0BF3 (Remote Device: 1649) [SELECTED] Device: 0BF2 (Remote Device: 164A) [SELECTED] Suspend RDF link(s)...started. Suspend RDF link(s)...done. The RDF 'SUSPEND' operation SUCCEEDED. 75

76 The RDF 'Suspend' operation successfully executed for device group 'app01'. # symrdf -g app01 query A symrdf query of the devices shows that the suspend was successful. Device Group (DG) Name : app01 DG's Type : RDF1 DG's Symmetrix ID : (Microcode Version: 5874) Remote Symmetrix ID : (Microcode Version: 5874) RDF (RA) Group Number : 12 (0B) Source (R1) View Target (R2) View MODES ST LI ST Standard A N A Logical T R1 Inv R2 Inv K T R1 Inv R2 Inv RDF Pair Device Dev E Tracks Tracks S Dev E Tracks Tracks MDAE STATE DEV001 0BE8 RW 0 0 NR 1640 WD 0 0 A... Suspended DEV002 0BE9 RW 0 0 NR 1641 WD 0 0 A... Suspended DEV003 0BEA RW 0 0 NR 1642 WD 0 0 A... Suspended DEV004 0BEB RW 0 0 NR 1643 WD 0 0 A... Suspended DEV005 0BEC RW 0 0 NR 1644 WD 0 0 A... Suspended DEV006 0BF0 RW 0 0 NR 1648 WD 0 0 A... Suspended Total Track(s) MB(s) Legend for MODES: M(ode of Operation) : A = Async, S = Sync, E = Semi-sync, C = Adaptive Copy D(omino) : X = Enabled,. = Disabled A(daptive Copy) : D = Disk Mode, W = WP Mode,. = ACp off (Consistency) E(xempt): X = Enabled,. = Disabled, M = Mixed, - = N/A The symmigrate query command, when used with the i interval options, allows for the query to be run automatically at the given interval (in seconds). After the second iteration of the query an estimated time to completion is included with the output, along with the current data transfer rate. symmigrate sid 54 name mig_01 query detail i 30 Symmetrix ID: Invalid Status Done TGT 76

77 Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 0AE SyncInProg RAID-5(7+1) mig_01 0BE9 0AE SyncInProg RAID-5(7+1) mig_01 0BEA 0C SyncInProg RAID-5(7+1) mig_01 0BEB 0C SyncInProg RAID-5(7+1) mig_01 0BEC 0AD SyncInProg RAID-5(7+1) mig_01 0BF0 0ACC SyncInProg RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 25 Copy rate : MB/S Estimated time to completion : 00:05:24 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 0AE SyncInProg RAID-5(7+1) mig_01 0BE9 0AE SyncInProg RAID-5(7+1) mig_01 0BEA 0C SyncInProg RAID-5(7+1) mig_01 0BEB 0C SyncInProg RAID-5(7+1) mig_01 0BEC 0AD SyncInProg RAID-5(7+1) mig_01 0BF0 0ACC SyncInProg RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 33 Copy rate : MB/S Estimated time to completion : 00:04:31 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 0AE SyncInProg RAID-5(7+1) mig_01 0BE9 0AE SyncInProg RAID-5(7+1) mig_01 0BEA 0C SyncInProg RAID-5(7+1) mig_01 0BEB 0C SyncInProg RAID-5(7+1) mig_01 0BEC 0AD SyncInProg RAID-5(7+1) mig_01 0BF0 0ACC SyncInProg RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 42 Copy rate : MB/S Estimated time to completion : 00:03:52 77

78 symdev show be8 -sid 54 While the migration is in the SyncInProg state, the output of a symdev show command shows the device being migrated as now being locally protected by two separate RAID groups the primary RAID 1 group that the device started with, and a secondary RAID 5 group to which the device is being migrated. The secondary RAID group can be seen to belong to diskgroup 1, while the primary RAID group belongs to diskgroup 0. Device Physical Name : /dev/rdsk/emcpower35c Device Symmetrix Name : 0BE8 Device Serial ID : 5400BE8000 Symmetrix ID : Device Group Name Device Logical Name : app01 : DEV001 Number of RAID Groups : 2... Device Configuration : RDF1+Mir... Device Service State : Normal Device Status : Ready (RW) Device SA Status : Ready (RW) Front Director Paths (3): { POWERPATH DIRECTOR PORT LUN PdevName Type Type Num Sts VBUS TID SYMM Host /dev/rdsk/emcpower35c PARENT FA 07E:0 RW B3 000 c1t d1s2 CHILD FA 07E:0 RW B3 000 c2t d1s2 CHILD FA 07F:1 RW } Mirror Set Type Mirror Set DA Status : [RAID-1,R2 Remote,RAID-5,N/A] : [RW,NR,RW,N/A] Mirror Set Inv. Tracks : [0,0,113293,0] Back End Disk Director Information { Hyper Type : RAID-1 Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A 78

79 Mirror Number : 1 Hyper Type : R2 Remote Hyper Status : Not Ready (NR) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 2 Hyper Type : RAID-5 Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 3 } RAID Group Information { Mirror Number : 1 RAID Type : RAID-1 Device Position : Primary Protection Level : 2 RAID Group Service State : Normal Failing Member Mask : N/A Hyper Devices: { Device : 0BE8 { Disk DA Hyper Member Disk DA :IT Vol# Num Cap(MB) Num Status Grp# Cap(MB) A:D RW A:D RW } } Mirror Number : 3 RAID Type : RAID-5 Device Position : Secondary Protection Level : 7+1 RAID Group Service State : Normal Failing Member Mask : N/A Hyper Devices: { Device : 0BE8 { Disk DA Hyper Member Disk DA :IT Vol# Num Cap(MB) Num Status Grp# Cap(MB) B:CD RW B:CD RW C:CD RW C:CD RW A:CD RW A:CD RW D:CD RW D:CD RW

80 } } }... symdev show ae7 -sid 54 While the migration is progressing, the target device specified will be shown to be a donor device. This indicates that it is providing the target storage for the migration. The donor status can be seen in the RAID Group Information section of the symdev show output of the target device. The device state is also shown as Not Ready. This is to prevent use of the device during the migration. Device Physical Name : Not Visible Device Symmetrix Name : 0AE7 Device Serial ID : N/A Symmetrix ID : Number of RAID Groups : 1... Device Configuration : RAID-5... Device Service State : Normal Device Status : Not Ready (NR) Device SA Status : N/A (N/A) Mirror Set Type Mirror Set DA Status : [RAID-5,N/A,N/A,N/A] : [NR,N/A,N/A,N/A] Mirror Set Inv. Tracks : [0,0,0,0] Back End Disk Director Information { Hyper Type : RAID-5 Hyper Status : Not Ready (NR) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 1 } RAID Group Information { Mirror Number : 1 RAID Type : RAID-5 Device Position : Primary (Donor) 80

81 Protection Level : 7+1 RAID Group Service State : Normal Failing Member Mask : N/A Hyper Devices: { Device : 0AE7 { Disk DA Hyper Member Disk DA :IT Vol# Num Cap(MB) Num Status Grp# Cap(MB) B:CD RW B:CD RW C:CD RW C:CD RW A:CD RW A:CD RW D:CD RW D:CD RW } } } At the end of the migration, the symmigrate query command will show the session status change from SyncInProg to Synchronized, to MigrInProg, and finally to Migrated. symmigrate sid 54 name mig_01 query detail i 30 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 0AE7 828 SyncInProg RAID-5(7+1) mig_01 0BE9 0AE9 0 Synchronized RAID-5(7+1) mig_01 0BEA 0C02 0 Synchronized RAID-5(7+1) mig_01 0BEB 0C SyncInProg RAID-5(7+1) mig_01 0BEC 0AD SyncInProg RAID-5(7+1) mig_01 0BF0 0ACC SyncInProg RAID-5(7+1) mig_01 Total Tracks MB(s) Done(%) 96 Copy rate : MB/S Estimated time to completion : 00:00:19 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 0AE7 0 Synchronized RAID-5(7+1) mig_01 0BE9 0AE9 0 Synchronized RAID-5(7+1) mig_01 81

82 0BEA 0C02 0 Synchronized RAID-5(7+1) mig_01 0BEB 0C03 0 Synchronized RAID-5(7+1) mig_01 0BEC 0AD0 0 Synchronized RAID-5(7+1) mig_01 0BF0 0ACC 0 Synchronized RAID-5(7+1) mig_01 Total Tracks 0 MB(s) 0 Done(%) 100 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 0AE7 0 MigrInProg RAID-5(7+1) mig_01 0BE9 0AE9 0 MigrInProg RAID-5(7+1) mig_01 0BEA 0C02 0 MigrInProg RAID-5(7+1) mig_01 0BEB 0C03 0 MigrInProg RAID-5(7+1) mig_01 0BEC 0AD0 0 MigrInProg RAID-5(7+1) mig_01 0BF0 0ACC 0 MigrInProg RAID-5(7+1) mig_01 Total Tracks 0 MB(s) 0.0 Done(%) 100 Symmetrix ID: Invalid Status Done TGT Src Tgt Tracks SRC => TGT (%) Dsk Grp TGT Protection Session Name BE8 0AE7 0 Migrated RAID-1 mig_01 0BE9 0AE9 0 Migrated RAID-1 mig_01 0BEA 0C02 0 Migrated RAID-1 mig_01 0BEB 0C03 0 Migrated RAID-1 mig_01 0BEC 0AD0 0 Migrated RAID-1 mig_01 0BF0 0ACC 0 Migrated RAID-1 mig_01 Total Tracks 0 MB(s) 0.0 Done(%) 100 Alternatively, the symmigrate verify command can be used to determine if all the devices in a single session have reached the state of Migrated. symmigrate name mig_01 sid 1254 verify -migrated All session(s) with name 'mig_01' are in 'Migrated' state. When the migration session has reached the Migrated status, the symdev show output now shows that the devices migrated are now, once again, 82

83 protected by a single local RAID group. However, the primary RAID group now is the RAID 5 group located on the SATA drives in diskgroup 1. symdev show be8 -sid 54 Device Physical Name : /dev/rdsk/emcpower35c Device Symmetrix Name : 0BE8 Device Serial ID : 5400BE8000 Symmetrix ID : Device Group Name Device Logical Name : app01 : DEV001 Number of RAID Groups : 1... Device Configuration : RDF1+R-5... Device Service State : Normal Device Status : Ready (RW) Device SA Status : Ready (RW) Front Director Paths (3): { POWERPATH DIRECTOR PORT LUN PdevName Type Type Num Sts VBUS TID SYMM Host /dev/rdsk/emcpower35c PARENT FA 07E:0 RW B3 000 c1t d1s2 CHILD FA 07E:0 RW B3 000 c2t d1s2 CHILD FA 07F:1 RW } Mirror Set Type Mirror Set DA Status : [RAID-5,R2 Remote,N/A,N/A] : [RW,RW,N/A,N/A] Mirror Set Inv. Tracks : [0,0,0,0] Back End Disk Director Information { Hyper Type : RAID-5 Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 1 Hyper Type : R2 Remote Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A 83

84 Hyper Number : N/A Mirror Number : 2 } RAID Group Information { Mirror Number : 1 RAID Type : RAID-5 Device Position : Primary Protection Level : 7+1 RAID Group Service State : Normal Failing Member Mask : N/A Hyper Devices: { Device : 0BE8 { Disk DA Hyper Member Disk DA :IT Vol# Num Cap(MB) Num Status Grp# Cap(MB) B:CD RW B:CD RW C:CD RW C:CD RW A:CD RW A:CD RW D:CD RW D:CD RW } } }... symdev show ae7 -sid 54 Also, the target device used in the migration now has the original storage previously associated with the device migrated. A symdev show output from the target device shows that it is now RAID 1 protected on storage configured in diskgroup 0. The device is also now ready again. Device Physical Name : Not Visible Device Symmetrix Name : 0AE7 Device Serial ID : N/A Symmetrix ID : Number of RAID Groups : 1... Device Configuration : 2-Way Mir... Device Service State : Normal Device Status : Ready (RW) Device SA Status : N/A (N/A) 84

85 Mirror Set Type Mirror Set DA Status : [RAID-1,N/A,N/A,N/A] : [RW,N/A,N/A,N/A] Mirror Set Inv. Tracks : [0,0,0,0] Back End Disk Director Information { Hyper Type : RAID-1 Hyper Status : Ready (RW) Disk [Director, Interface, TID] : [N/A,N/A,N/A] Disk Director Volume Number : N/A Hyper Number : N/A Mirror Number : 1 } RAID Group Information { Mirror Number : 1 RAID Type : RAID-1 Device Position : Primary Protection Level : 2 RAID Group Service State : Normal Failing Member Mask : N/A Hyper Devices: { Device : 0AE7 { Disk DA Hyper Member Disk DA :IT Vol# Num Cap(MB) Num Status Grp# Cap(MB) A:D RW A:D RW } } } To complete the migration, and to remove the migration session from the Symmetrix, the symmigrate terminate command is run. symmigrate -sid 54 -name mig_01 terminate -v -nop 'Terminate' operation execution is in progress for the session named 'mig_01'. Please wait... STARTING a Migrate 'TERMINATE' operation. SELECTING the list of Source devices: Devices: [SELECTED] Terminate Migration...Started. Terminate Migration...Done. 85

86 The Migrate 'TERMINATE' operation SUCCEEDED. 'Terminate' operation successfully executed for the session named 'mig_01'. A subsequent query shows the session no longer exists. symmigrate -sid 54 -name mig_01 query Symmetrix ID: The device list with session name 'mig_01' does not have any session information. The Virtual LUN migration is now complete. Migration to unconfigured space using SMC In this example, the six R1 devices will be migrated to unconfigured space on SATA drives using Symmetrix Management Console. To determine which diskgroup to perform the migration to, the diskgroup properties can be viewed by selecting the Symmetrix in the left-hand navigation pane and navigating to Disks > Disk Groups and selecting the diskgroup number. Figure 33 shows diskgroup 1 containing 1 TB SATA drives. 86

87 Figure 33 Symmetrix physical diskgroup 1 The inset in Figure 33 shows the individual drives in the diskgroup to help determine if there is sufficient freespace in the diskgroup, and sufficient DAs and physical drives to support RAID devices. Prior to migrating the device, the properties of one of the devices to be migrated shows that the device is locally protected by a single RAID 1 primary RAID group, configured in diskgroup 0, as well as remotely protected. 87

88 Figure 34 Source device properties before migration 88

89 Once the devices to be migrated, and the diskgroup to be migrated to, have been identified, along with the desired protection type, the migration can be submitted to the array. First, with the appropriate Symmetrix selected, the Tasks view is displayed, then the LUN Migration Wizard is selected. Figure 35 Tasks view showing LUN Migration Wizard 89

90 The first screen of the LUN Migration Wizard directs the user as to what information will be needed to submit and complete the migration. To continue to selecting the source devices, click the Next button. Figure 36 LUN Migration Wizard Welcome screen 90

91 After the Symmetrix has been selected, and a session name provided, the source devices can be specified by one of three ways: Manual selection (Ungrouped) Device group Storage group Here, the source devices will be specified by device group. Figure 37 Source device criteria selection 91

92 Once the group type has been set, clicking the Select button will produce a popup screen listing all the device groups for the Symmetrix. Figure 38 Device group selection 92

93 When the device group has been selected, in this case app01, click OK. At this point the devices within the group are displayed in the Selected Source Devices panel. Figure 39 Selected Source Devices Now, click the Next button to display the migration type screen, where a migration to unconfigured or configured space can be selected. 93

94 In this example, the migration will be performed to unconfigured devices. When the radio button is selected, the desired protection type of the devices and the destination diskgroup are selected. Figure 40 shows the protection type being set to RAID and the disk group to diskgroup 1. Figure 40 Select Migration Type: Unconfigured devices Clicking the Next button validates the migration request. 94

95 If the validation is successful, a summary screen is displayed showing the migration details, as shown in Figure 41. Figure 41 LUN Migration Wizard Summary To commit the migration, click the Finish button. 95

96 Once a migration is in progress, the left-hand navigation pane displays a Migration Sessions folder. This can be expanded to display individual migration sessions. Properties, and devices, of the session can be displayed by highlighting the session name (Figure 42). Figure 42 Migration session properties In order to view an updated status of the session, click the Refresh View button in the upper right-hand corner. 96

97 While the migration is running, it is possible to perform TimeFinder/Clone operations against the devices being migrated. Here, the TimeFinder/Clone window is displayed by right-clicking on the device group name and then choosing Replication and TimeFinder/Clone, as shown in Figure 43. Figure 43 Selecting TimeFinder/Clone for device group app01 97

98 The Clone session is first recreated by setting the Action to Recreate. All devices in the group are highlighted by clicking Select All and then clicking the Next button. Figure 44 Setting up a Clone session recreate 98

99 After clicking Next, the precopy option is selected and the Finish button clicked to perform the recreate. Figure 45 Completing the Clone session recreate 99

100 Selecting the Clone query tab on the device group properties view shows that the recreate was successful, as shown in Figure 46. Figure 46 Clone session query 100

101 The Clone session can also be activated during the Virtual LUN migration, shown in Figures 47, 48, and 49. Figure 47 Setting up a Clone session activate 101

102 Figure 48 Completing the Clone session activate 102

103 Figure 49 Clone session query 103

104 While the migration is in the SyncInProg state, the property view of one of the devices being migrated shows that the device is now locally protected by two separate RAID groups the primary RAID 1 group that the device started with, and a secondary RAID 5 group to which the device is being migrated. The secondary RAID group can be seen to belong to diskgroup 1, as shown in Figure 50. Figure 50 Source device properties view during migration 104

105 At the end of the migration, the migration session status will show as Migrated. Figure 51 Migration session showing a status of migrated 105

106 When the migration session has reached the Migrated status, the properties view of the source devices shows that it is now, once again, protected by a single local RAID group. However, the primary RAID group now is the RAID 5 group configured on the SATA drives in diskgroup 1, as shown in Figure 52. Figure 52 Source device properties view after migration 106

107 To complete the migration, and to remove the migration session from the Symmetrix, right-click on the migration session name, then choose Migration > Terminate Migration Session. A popup window will confirm the termination request, as shown in Figure 53. Figure 53 Terminating the migration session After clicking Yes the Virtual LUN migration is complete. 107

108 Migration to configured space using SMC In this example, the six R1 devices will be migrated to configured space on SATA drives using Symmetrix Management Console. To determine which diskgroup to perform the migration to, the diskgroup properties can be viewed by selecting the Symmetrix in the left-hand navigation tree and navigating to Disks > Disk Groups and selecting the diskgroup number. Figure 54 shows diskgroup 1 containing 1 TB SATA drives. Figure 54 Symmetrix physical diskgroup 1 Once it has been determined that diskgroup 1 contains the SATA drives, then unmapped devices can be looked at to determine if there are sufficient targets to complete the migration. 108

109 Prior to migrating the device, the properties of one of the devices to be migrated shows that the device is locally protected by a single RAID 1 primary RAID group, configured in diskgroup 0, as well as remotely protected. Figure 55 Source device properties before migration 109

110 Once the devices to be migrated, and the diskgroup to be migrated to, have been identified, along with the desired protection type, the migration can be submitted to the array. First, with the appropriate Symmetrix selected, the Tasks view is displayed, then the LUN Migration Wizard is selected. Figure 56 Tasks view showing LUN Migration Wizard 110

111 The first screen of the LUN Migration Wizard directs the user as to what information will be needed to submit and complete the migration. To continue to selecting the source devices, click the Next button. Figure 57 LUN Migration Wizard Welcome screen 111

112 After the Symmetrix has been selected, and a session name provided, the source devices can be specified in one of three ways: Manual selection (Ungrouped) Device group Storage group Here, the source devices will be specified by device group. Figure 58 Source device criteria selection 112

113 Once the group type has been set, clicking the Select button will produce a pop-up window listing all the device groups for the Symmetrix. Figure 59 Device group selection 113

114 When the device group has been selected, in this case app01, click OK, and the devices within the device group are displayed in the Selected Source Devices panel. Figure 60 Selected source devices At this point, click the Next button to display the migration type selection screen, where a migration to unconfigured or configured space is selected. 114

115 In this example, the migration will be performed to configured devices. When the radio button is selected, the desired protection type of the devices and the destination diskgroup are selected. Figure 61 shows the protection type being set to RAID and the disk group to diskgroup 1. Figure 61 Select Migration Type: Configured devices Clicking the Next button validates the migration request. 115

116 If the validation is successful, the recommended target devices for each source device are displayed. As can be seen in Figure 62, multiple target devices are listed for the metadevices being migrated. Figure 62 Recommended target devices Highlighting one of the devices activates the Select Other Target Devices button. 116

117 Clicking the Select Other Target Devices button displays the pop-up window shown in Figure 63. Figure 63 Select Other Target Devices From this screen recommended devices can be removed, and other devices added to the migration target list. 117

118 Clicking OK returns control to the Select Target Devices screen. Figure 64 Confirming selected target devices Clicking Next on the Select Target Devices screen validates the migration with the selected target devices. 118

119 If the validation is successful, a summary screen is displayed showing the migration details, as seen in Figure 65. Figure 65 LUN Migration Wizard summary To commit the migration, click the Finish button. 119

120 Once a migration is in progress, the left-hand navigation pane displays a Migration Sessions folder. This can be expanded to display individual migration sessions. Properties, and devices, of the session can be displayed by highlighting the session name, as show in Figure 66. Figure 66 Migration session properties and status In order to view an updated status of the session, click the Refresh View button, in the upper right-hand corner of the screen. 120

121 While the devices are migrating it is possible to use them in normal replication functions, such as SRDF. Here, the SRDF window is displayed by right-clicking on the device group name and then choosing Replication > SRDF Control. Figure 67 Selecting SRDF Control for device group app01 121

122 The SRDF pairs are split by setting the Action to Split. All devices in the group are highlighted by clicking Select All and then clicking the Next button. Figure 68 Setting up an SRDF split 122

123 After clicking Next, click the Finish button to perform the split. Figure 69 Completing the SRDF split 123

124 Selecting the RDF query tab on the device group properties view shows that the split operation was successful. Figure 70 SRDF query of devices being migrated 124

125 While the migration is in the SyncInProg state, the properties view of one of the devices being migrated shows that the device is now locally protected by two separate RAID groups the primary RAID 1 group which the device started with, and a secondary RAID 5 group to which the device is being migrated. The secondary RAID group can be seen to belong to diskgroup1, as shown in Figure 71. Figure 71 Source device properties view during migration 125

126 At the end of the migration, the migration session status will show as Migrated. Figure 72 Migration session showing a status of Migrated 126

127 When the migration session has reached the Migrated status, the properties view of the source device shows that it is now, once again, protected by a single local RAID group. However, the primary RAID group now is the RAID 5 group located on the SATA drives in diskgroup 1, as shown in Figure 73. Figure 73 Source device view after migration 127

128 Also, the target device used in the migration now has the original storage previously associated with the device migrated, as shown in Figure 74. Figure 74 Target device after the migration 128

129 To complete the migration, and to remove the migration session from the Symmetrix, right-click on the migration session name, then choose Migration > Terminate Migration Session. A popup window confirms the termination request, as shown in Figure 75. Figure 75 Terminating the migration session After clicking Yes the Virtual LUN migration is complete. 129