Symmetrix Optimizer Virtual LUN Technology · PDF fileSymmetrix Optimizer Virtual LUN Technology A Detailed ... overview of data migration strategies and ... EMC Symmetrix® DMX-3

Symmetrix Optimizer Virtual LUN Technology A Detailed Review

Abstract

This white paper describes the features, benefits, and use cases of Symmetrix® Optimizer Virtual LUN technology, available with Symmetrix storage systems beginning with Enginuity™ release 5772. It provides an overview of data migration strategies and value propositions, and provides detailed examples of virtual LUN migration, including use in a tiered storage array.

October 2007

Copyright © 2007 EMC Corporation. All rights reserved.

EMC believes the information in this publication is accurate as of its publication date. The information is subject to change without notice.

THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC Corporation Trademarks on EMC.com

All other trademarks used herein are the property of their respective owners.

Part Number H2964

Symmetrix Optimizer Virtual LUN Technology A Detailed Review 2

Table of Contents Executive Summary............................................................................................4 Introduction.........................................................................................................4

Audience ...................................................................................................................................... 4 Information Lifecycle Management ...................................................................4

Tiered Storage ............................................................................................................................. 5 Data Migration Challenge ............................................................................................................ 6 Storage Consolidation.................................................................................................................. 6

EMC Symmetrix Optimizer Migration ................................................................6 Virtual LUN Management ...................................................................................7

Differentiation............................................................................................................................... 7 Reacting to changing information value....................................................................................... 7 System reconfiguration ................................................................................................................ 8

Virtual LUN Management Examples..................................................................8 SMC Device Group Manual Move Example ................................................................................ 8 SMC Array Manual Move Example with Monitoring Enable & Stop .......................................... 11 Symmetrix Management Console Groups and Rules Example ................................................ 15 Solutions Enabler symoptmz Example ...................................................................................... 21

Conclusion ........................................................................................................24 References ........................................................................................................24


Executive summary No matter how large a company may be, enterprise employees, their customers and partners have rigorous – and variable – data performance and availability requirements. Continuous access to mission-critical information helps enterprises maintain a competitive edge over their competition. Data availability issues can have a negative impact on both productivity and sales. Adding to the complexities of keeping this information readily available is the requirement to keep more and more data online.

At the same time, the information infrastructure must continuously adapt to changing business requirements. Storage systems must be reconfigured to add capacity, consolidate storage, and optimize performance. All of these add value to your organization; however, they also might impact the ability to meet service levels. In addition, there is a need to align the business value of information with appropriate storage levels and manage costs effectively.

EMC Symmetrix® DMX-3 and DMX-4 with Virtual LUN technology introduced in Enginuity™ 5772 enables data migration within an array without host or application disruption. Virtual LUNs enable you to bring your Information Lifecycle Management (ILM) strategy to life by easily moving information throughout the storage system as its value changes over time. It can assist in system reconfiguration, performance improvement, and consolidation efforts all while helping maintain vital service levels.

Introduction Virtual LUN technology is an enhancement to the Symmetrix Optimizer product that enables transparent, nondisruptive data mobility among storage tiers within the same array with devices of the same RAID protection scheme. Virtual LUN technology is supported for both open system and mainframe platforms, and includes support for metavolumes.

In addition to Symmetrix Optimizer Virtual LUN technology, Enginuity™ 5772 provides two other new mechanisms for providing different levels of service to each application tier. Symmetrix Priority Controls can be used to guarantee preferential processing for higher-priority applications. Dynamic Cache Partitioning divides cache into multiple partitions and can be used to maintain predictable performance with tiered storage in the box.

Virtual LUN technology offers two types of data movement: migration and relocation. Migration provides users the ability to move data between high-performance disks and high-capacity disks, or to populate newly added disk drives. Relocation is used to support rollbacks, which can be invoked by users to undo migrations that conflict with business rules. For example, an administrator might identify with a business rule that, even though a volume has been migrated, that volume in fact should continue to reside in the high-priority location. Therefore the relocation rollback would be invoked to put it back to its priority location.

Audience This white paper provides an overview of the Virtual LUN technology for the DMX-3 and DMX-4 arrays and outlines the features and business benefits. The intended audience includes customers, decision-makers, EMC staff and partners who are evaluating the differentiation of the Symmetrix DMX™ platform.

Information Lifecycle Management Information Lifecycle Management (ILM) is the practice of aligning the business value of information with the most appropriate and cost-effective infrastructure throughout its existence. The effective use of ILM allows users to lower the total cost of ownership (TCO) while still maintaining high service levels for the data and applications that are accessed the most. Costs can be reduced by moving “lower-tier” data with less rigorous performance and availability requirements to cheaper infrastructure, while maintaining tier-one data on higher-performance drives. Figure 1 highlights the overall ILM strategy.


Figure 1. The ILM philosophy

Reducing total cost can be accomplished by swapping out higher-priced, underutilized infrastructure with more cost-effective alternatives for the appropriate lower storage tiers. Coupling this cost reduction with an increase in business value, however, proves a very difficult task. Companies must examine their “one size fits all” service level philosophy to determine which applications require the highest performance. Furthermore, the value of data flowing through those applications must also be examined to ensure that the most important information is receiving the best resources (see Figure 2). Replacing a homogenous infrastructure with tiered storage can improve service levels and reduce risks for tier-one applications, while also improving the efficiency of lower-tier application storage.

Not enough: service level shortfall exposes organization to higher risk

Too much: higher cost than needed

Actual service level required to support the business

Serv

ice

Leve

l Req

uire

d

Information Infrastructure for Each Application

Figure 2. One-size-fits-all service level deployment

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. This is typically the first step toward creating a complete and efficient storage environment. 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. Tiered storage must also include the ability to freely move data among storage tiers to respond to rapidly changing information value and business needs. EMC Symmetrix Optimizer migrates data between storage tiers within the same array. EMC also has a number of products for migrating data


between different storage arrays, including EMC Invista™, EMC Open Replicator, and EMC PowerPath® Migration Enabler.

Data migration challenge Data migration should not be overlooked in complex, expensive storage environments. ILM 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, and without it information remains on storage levels that do not correspond to its value. The challenge is that migration is normally associated with system downtime, which adversely affects the ability to meet service level agreements (SLAs). Furthermore, many migration techniques require additional software licenses, adding greater expense. These issues prevent many users from effectively moving data because of their reluctance to disturb their system or create application downtime. As more and more information is stored digitally, users demand easier ways to migrate information without disrupting their systems. Virtual LUN technology, available as a feature of Symmetrix Optimizer, is an important tool to address this requirement.

Storage consolidation The Symmetrix architecture enables you 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 to more than 1 PB, enabling massive scalability and tiering within a single system, and providing significant cost savings through operational efficiencies. Symmetrix Optimizer Virtual LUN technology provides the essential ability to migrate data throughout the array easily and without downtime to effectively merge storage consolidation with ILM.

EMC Symmetrix Optimizer migration Symmetrix Optimizer improves array performance by continuously monitoring access patterns and swapping devices (Symmetrix logical volumes) to achieve balance across the disks in the array. This automated process utilizes user-defined parameters and is completely transparent to end users, hosts, and applications in the environment. Swapping is performed with constant data availability and protection. A typical swap would move a highly accessed device from a busy disk spindle to a less busy disk spindle, and at the same time move a less highly accessed device from the less busy disk spindle to the busy disk spindle. The result of the swap improves overall disk performance by increasing the number of disk requests that can be processed simultaneously because requests are better balanced across the multiple disk spindles.

With Enginuity 5772, Symmetrix Optimizer can now perform migrations in addition to swaps. The key difference is that the user must initiate the desired migration and there must be unallocated disk space for the new location of the data. When a single device is being moved to unallocated space, there is no swap of locations for two devices. However the pre-migration location of the device becomes unallocated and can be used for a new purpose.

Migration moves devices from an old to a new location. The user only defines the destination as a group of similar disks or a single disk drive. High-performance disks would be grouped separately from high-capacity disks, making it easy to migrate devices to the appropriate tier of storage.

Migration contains the following features:

One or more devices moved to one or more target disks. All mirrors of the devices are moved. Migrated volumes are distributed across specified recipient drives by a sophisticated layout

algorithm. Final placement of the volumes is not known in advance. After completion of the migration, the original volumes are deleted from their original locations.


Virtual LUN management The migration feature is based on Optimizer swap technology and shares the same requirements as the traditional swap environment. Dynamic Relocation Volumes (DRVs) must be available to provide additional protection during the data movement process. Only devices with a matching sized DRV are eligible for Optimizer Virtual LUN control. RAID 6 devices are an exception and do not require a DRV, since the two parity devices already provide double protection.

Data migration and relocation consume array resources and user-definable limits can be placed on such resource expenditure. The maximum number of volumes that can be moved each day and the maximum simultaneous volumes to be moved work together to determine resources that are used for the process. A priority value can also be assigned to the copy process of each participant volume. Together, these parameters affect how long a migration or relocation will take. The Symmetrix configuration lock will remain in place while the Virtual LUN data movement is in progress. If other configuration management functions are routinely scheduled, the Virtual LUN process will be limited by the maximum simultaneous volumes and maximum number of volumes to ensure completion within a timeframe that would allow the configuration lock to be released for other activities.

Optimizer Virtual LUN functionality moves the logical volume as a complete entity including all mirrors of the device. Subsets of data that reside on the logical volumes remain unknown to the process. Consequently, users are advised to understand data placement and assign related data to grouped logical volumes.

Virtual LUNs accomplish this without application downtime, providing the ability to meet service levels.

Figure 3 diagrams the Symmetrix Optimizer migration process.

Fibre Channel Raid 1

15,000 rpm 146GB

ATA Raid 1

7200 rpm 500GB

Tier 2 Volume

00100100100

Tier 1 Volume

Figure 3. Virtual LUNs in action

Differentiation Symmetrix DMX systems provide a number of ways to migrate data internal to the same storage array, including using products such as EMC TimeFinder®/Mirror and TimeFinder/Clone. TimeFinder is principally a local replication product. Redirecting an application to point to the replicated data in its new location is effectively a data migration. This method can be used when the necessity of bringing the application offline to point to the new LUN is acceptable.

After a LUN is moved using Optimizer Virtual LUN technology, the LUN retains all of the characteristics of the original LUN, including its name and ID so there is no need to bring the application offline.

Reacting to changing information value Virtual LUNs allow users to move data to cheaper or better performing devices internal to an array as the value of that data changes over time. For example, historical data within a database, which is not accessed very often, can be migrated from higher-performance to higher-capacity drives. This “archiving” of data frees up the better performing drives for the information that is most valuable to system users. Virtual


LUNs allow all this to be done without the database having any knowledge that a transition is being done, and also without ever having to take the database offline.

System reconfiguration In many instances, a storage system will have to be reconfigured while running live. For example, users may need to add additional capacity to an array to respond to increasing storage demands. Or users may want to move an application using higher-capacity drives to higher-performance drives to increase performance. Virtual LUNs allow users to migrate the data stored on existing disk drives to newly added disk drives while the host applications remain online.

Virtual LUN management examples Symmetrix Optimizer and its Virtual LUN component can be managed with the following tools that support 5772 features:

Symmetrix Management Console (SMC) Solutions Enabler Command Line Interface (Using the symoptmz command)

All of the migration management methods involve first selecting the device(s) to be moved, second selecting the target disk(s) for the new migrated location, and third confirming and scheduling when to begin the migration. The methods vary in the simplicity, flexibility, and robustness in each of these steps. The rest of this white paper provides complete detail on each of these methods. Readers only interested in getting an idea of how to migrate a LUN without all of the details may choose to look at only the first example, then skip to the “Conclusion” section. The examples in this paper include the latest Optimizer Virtual LUN technology at the time of publication, including features new in the Enginuity August 2007 service release, SMC 6.0.2, and Solutions Enabler 6.4.2.

SMC Device Group Manual Move Symmetrix Management Console (SMC) provides three methods for managing Optimizer migration. The first two methods both require you to select the Manual Move menu, but they differ in starting from right-clicking a device group or the Symmetrix array in the Navigation tree. Clicking a device group is the easiest migration method, because the already defined device group is used to quickly select all of the application devices to be migrated. Additionally, when this method is used, SMC presents a very simple checkbox for selecting the target disks.

This first example begins from a device group selecting Optimizer > Swap/Move > Manual Move. Figure 4 shows the menu selection from the device group.


Figure 4. Manual Move menu selection from a device group

Figure 5 shows step 1 of the SMC migration, which is in effect a verification where all of the devices in the device group are already selected and clicking Next will continue to step 2. The user could remove some of the devices from the Selected Devices list if needed.

Figure 5. Step 1 of SMC device group migration


Figure 6 shows step 2 of the SMC migration: selecting the target disks. Because this dialog began by selecting a device group, only very simple checkbox options for selecting a disk class for the target disks are provided. By default the devices are only moved to Free Disk Space (unallocated) on the Selected Disks. Checkboxes are available to indicate that the devices can also be moved to use the space of Unmapped and/or Unmasked Devices.


Figure 7 shows step 3 of the SMC migration: scheduling the data move. The start of the Virtual LUN process can be scheduled in this SMC window, or it can start according to policies defined in the Optimizer program. Other Optimizer parameters, such as maximum simultaneous volumes, maximum number of volumes, and priority, will affect the runtime of the Virtual LUN migration. In this example, an explicit start time is specified.



SMC Array Manual Move with Monitoring Enable & Stop This second SMC Optimizer Manual Move example begins from the array selection, providing for the user to explicitly select devices and target disks. This example also includes the steps that may be necessary to initially enable Optimizer Monitoring in SMC and the requirement to stop the automated Optimizer processing before a Manual Move can be scheduled. The initial menu for Manual Move is grayed out until Optimizer monitoring is enabled in SMC as shown in Figure 8. Select the Administration > Optimizer Monitoring menu, select the checkbox(es) for the Symmetrix ID(s) in the dialog box and click OK. Note that Optimizer actions often take enough time for the Progress Bar to be displayed in SMC because Optimizer actions are actually performed on the Symmetrix service processor and SMC has to wait for a response from the Optimizer Server that it has completed the action.

Figure 8. Enabling Optimizer Monitoring in SMC

This example begins from the Symmetrix array selecting Optimizer > Swap/Move > Manual Move. Optimizer currently does not permit migrations to be defined while it is in the Started state, so this selection will fail once the Optimizer Server responds that it is in enabled mode.


Figure 9 shows the menu selection and the dialog box to inform the user that Optimizer must be stopped first.

Figure 9. Manual Move menu selection and Optimizer is not stopped error message


Optimizer can be stopped by right-clicking the array and selecting Optimizer > Start/Stop/Lock/Unlock …, then clicking Stop, confirming the operation, and closing the dialog box as shown in Figure 10.

Figure 10. Stopping Optimizer


Now that Optimizer is in the correct state, the Manual Move dialog can proceed. This example begins from the Symmetrix array selecting Optimizer > Swap/Move > Manual Move. All devices with an appropriately sized DRV and RAID 6 devices will be displayed in the list of available devices. The Available Devices list can be filtered by device Configuration or Capacity. By default only the Meta Head is displayed for Meta Devices unless the Show Meta Members checkbox is selected.

Figure 11 shows step 1 of the SMC migration, after two devices have been highlighted and the Add button was clicked to move them into the Selected Devices list. This is the same screen as Figure 5 from the device group example. The difference is that when first entered there are no devices in the Selected Devices list and the Available Devices list has devices beyond the membership in a single device group.

Figure 11. Step 1 of SMC migration


Figure 12 shows step 2 of the SMC migration: selecting the target disks. The Available Disks list can be filtered by the disk Capacity and performance (RPM), which can be easily used to select the appropriate tier of storage. It is important to note that disks containing the source devices are excluded from the migration target disks. Again, checkboxes are available to indicate that the devices can also be moved to use the space of Unmapped and/or Unmasked Devices. Figure 12 shows the screen after tier 2 500 GB disks were selected and where the Next button is clicked to move onto step 3 (not shown but it is the same as Figure 7).

Figure 12. Step 2 of SMC migration

Symmetrix Management Console groups and rules Both of the Manual Move examples mentioned previously will run a single time as scheduled. The third SMC method for scheduling a migration requires some initial definitions or groups and rules, but will run again as necessary to ensure that the defined groups and rules are adhered to.

The four basic steps of rules based migration are:

1. Build up various Optimizer Disk Groups according to business requirements such as "Fast drives," "Archive drives," "Drives for Eng department," "Drives to be replaced,"and others. Make sure to treat each group as if they were "virtual Symmetrix arrays" that qualify for the major configuration rules such as enough distribution under directors, loops, power branches, and so on.

2. Build up Optimizer Device Groups such as "Devices for eng," "high speed Devices," "Archived data," and so on.


3. Add Optimizer Device Rules that use an Optimizer Device Group, an Optimizer Disk Group,

specify a Priority, and schedule into rule-based operation.

4. Allow Optimizer to do the work for you

Figure 13 shows the menu selection by right-clicking the Symmetrix array Optimizer > Settings … and the General tab of the Settings where the migration-related values Maximum Number of Volume(s) Moved per Day and Maximum Simultaneous Volume(s) Moved can be set.

Figure 13. Optimizer Settings General tab


Figure 14 shows the Device Attributes tab of the Settings where devices that were manually moved can be made not eligible for automatic swapping when Optimizer is Started (enabled).

Figure 14. Optimizer Settings Device Attributes tab setting No Swap

Figure 15 shows the initial Groups & Rules tab with no Disk Rules or Disk Groups defined. The New… button is clicked to open the dialog box to create an Optimizer Disk Group.

Figure 15. Optimizer Groups & Rules tab


Figure 16 shows the creation of an Optimizer Disk Group. In this example a Group Name(d) tier2 is created containing all of the 500 GB drives. Symmetrix Disk Groups that will be used in the following SYMCLI symoptmz migration example are created by EMC support personnel and cannot be created or edited by users.

Figure 16. Creating a Optimizer Disk Group

Figure 17 shows the drop-down menu to switch to device Device Rules & Groups instead of Disk Rules & Groups. To get to Figure 18, the New … button under Device Groups on the right side is clicked.

Figure 17. Switch to Device Rules & Groups


Figure 18 shows the creation of an Optimizer Device Group. In this example the device range filter was used to only list the devices to be added to the group in the Candidate List. A Group Name(d) lowtierappl is defined. Note this Optimizer Device Group is distinct from Device Groups listed in the Navigation Tree.

Figure 18. Optimizer Device Group creation

Figure 19 shows the Groups & Rules tab displaying the defined lowtierappl Group and the New … button is clicked to open the Device Rule dialog box in Figure 20.

Figure 19. Click New … to create a Device Rule


Figure 20 shows the creation of the Device Rule lowtierap_to_tier2. This example uses the previously defined Optimizer Device Group and Optimizer Disk Group to define a rule of Type Migration. The migration Priority is set to the middle Normal setting and a start time for the rule is specified. A rule can also be marked as not active by clicking the No radio button. OK is clicked to close the dialog box.

Figure 20. Optimizer Device Rule creation

Figure 21 shows the Groups & Rules Tabs after the Device Rule lowtierap_to_tier2 is created. From this screen existing rules can be edited or new rules and groups defined. The OK button is clicked to send this rule to the Optimizer Server and close the dialog box.

Figure 21. Click OK to send the newly defined rule to the Optimizer Server


Figure 22 shows the Information dialog box that is displayed after the newly defined Groups & Rules have been successfully sent to Optimizer. Note that in order to take effect, Optimizer must be started to automatically act upon the Rules.

Figure 22. Reminder to start Optimizer for rules to be in effect

Solutions Enabler symoptmz Virtual LUN migration does not include any substantial changes to the symoptmz command itself, only additional syntax for use in the command file to specify the migration. The one minor change is that the -swap_list option actually lists both swaps and migrations, so the option has been duplicated as the more generic -activity_list option, which more clearly represents both swaps and migrations. The four new sets of command file syntax for initiating a migration are listed below. The first set migrates one or more devices to one or more disks requiring each to be listed specifically. The second set is more convenient, moving the set of devices in a device group to one or more disk groups (assuming that disk groups have been set up to group together disks in the same performance tier). The third and fourth sets are variants on combining the first two sets, mixing the specific and grouping syntax.

migrate dev[s] <start_dev1>[:<end_dev1>] [,<start_dev2>[:<end_dev2>],...] TO disk[s] {disk1} [,{disk2},...] [unmapped=TRUE] [unmasked=TRUE] [begin_at=<time_val>]; migrate device_group <dgname> TO disk_group_num <disk_group_num> [unmapped=TRUE] [unmasked=TRUE] [begin_at=<time_val>]; migrate device_group <dgname> TO disk[s] {disk1} [,{disk2},...] [unmapped=TRUE] [unmasked=TRUE] [begin_at=<time_val>]; migrate dev[s] <start_dev1>[:<end_dev1>] [,<start_dev2>[:<end_dev2>],...] TO disk_group_num <disk_group_num> [unmapped=TRUE] [unmasked=TRUE] [begin_at=<time_val>];


By default data will only be moved to unallocated space on disk. The unmapped and/or unmasked options can be set to TRUE, meaning that unmapped or unmasked devices will be used as potential destinations for the move. The begin_at time value can be used to override the swap time windows that also apply to migrations. Other settings like the max_simult_swaps control parameter apply to migrations as well as swaps.

For this example the second format listed previously will be used. In order to see which devices are to be moved the device group membership must be displayed. The verbose option is used, which includes the back-end disk director information and it can be seen that both source devices displayed are tier 1 volumes in Disk Group 1.

c:\>symld -g low_tier_application list -v Device Group (DG) Name: low_tier_application DG's Type : REGULAR DG's Symmetrix ID : 000190300709 . . . Device Symmetrix Name : 0070 . . . Device Group Name : low_tier_application Device Logical Name : DEV001 . . . Back End Disk Director Information . . . Disk [Director, Interface, TID] : [02A, C, 1] . . . Disk Group Number : 1 . . . Disk [Director, Interface, TID] : [01A, C, 0] . . . Disk Group Number : 1 } . . . Device Symmetrix Name : 0071 . . . Device Group Name : low_tier_application Device Logical Name : DEV002 . . . Device Configuration : 2-Way Mir (Non-Exclusive Access) . . . Back End Disk Director Information . . . Disk [Director, Interface, TID] : [15B, D, 0] . . . Disk Group Number : 1 . . . Disk [Director, Interface, TID] : [16B, D, 1] . . . Disk Group Number : 1 }


In order to see which disks are potential destinations for the migration, the disk groups need to be displayed. The output has been edited so not all disks are displayed. Again the disks that include the devices to be migrated are in Disk Group 1 and the destination disks will be defined as belonging to Disk Group 2.

c:\>symdisk -sid 709 -by_diskgroup list Symmetrix ID : 000190300709 Disks Selected : 120 Capacity(MB) Ident Symb Int TID Vendor Type Hypers Total Free Actual ------ ---- --- --- ---------- ---------- ------ -------- -------- -------- Disk Group 1: DF-1A 01A C 0 SEAGATE T146155 37 140014 30756 140014 DF-1A 01A C 2 SEAGATE T146155 37 140014 30506 140014 . . . DF-2A 02A C 1 SEAGATE T146155 37 140014 30756 140014 DF-2A 02A C 3 SEAGATE T146155 37 140014 30506 140014 . . . DF-15B 15B D 0 SEAGATE T146155 38 140014 30663 140014 DF-15B 15B D 2 SEAGATE T146155 37 140014 30506 140014 . . . DF-16B 16B D 1 SEAGATE T146155 38 140014 30663 140014 DF-16B 16B D 3 SEAGATE T146155 37 140014 30506 140014 . . . Disk Group 2: DF-1A 01A C 8 SEAGATE BL500LP 34 476837 59768 476837 DF-1A 01A C A SEAGATE BL500LP 34 476837 52685 476837 . . . DF-2A 02A C 9 SEAGATE BL500LP 34 476837 59768 476837 DF-2A 02A C B SEAGATE BL500LP 34 476837 52685 476837 . . . DF-15A 15A C 0 SEAGATE BL500LP 37 476837 30756 476837 DF-15A 15A C 2 SEAGATE BL500LP 37 476837 36261 476837 DF-15A 15A C 4 SEAGATE BL500LP 36 476837 33244 476837 DF-15A 15A C 6 SEAGATE BL500LP 36 476837 38749 476837 . . . DF-2B 02B D 1 SEAGATE BL500LP 37 476837 30756 476837 DF-2B 02B D 3 SEAGATE BL500LP 37 476837 36261 476837 DF-2B 02B D 5 SEAGATE BL500LP 36 476837 33244 476837 DF-2B 02B D 7 SEAGATE BL500LP 36 476837 38749 476837 DF-2B 02B D 9 SEAGATE BL500LP 34 476837 59768 476837 . . . The command file migrate.txt simply defines the migration by defining the device group and disk group for the migration. In this file, the begin_at option is also used to explicitly set the time the migration should begin.

migrate device_group low_tier_application TO disk_group_num 2 begin_at=09202007:220000;


The last step is to initiate the migration using the symoptmz command. At the completion of this step, the migration has been successfully submitted to Optimizer, which will begin the migration according to the specified begin_at time. C:\>symoptmz -sid 709 -file migrate.txt commit Processing Command file : migrate.txt PREVIEW ..............................Started. PREVIEW ..............................Done. PREPARE ..............................Started. PREPARE ..............................Done. COMMIT ..............................Started. COMMIT ..............................Done. Closing Optimizer Session ............Done.

Conclusion Organizations today are under increasing pressure to reduce costs within their infrastructure, and an effective ILM strategy can help do this. However, in order to improve the business value of that information, organizations need to control it during every stage of its life cycle. With the power to quickly and easily migrate data within a storage array without interruption, an organization can increase its return on investment and lower the total cost of ownership by aligning hardware performance with data value, while increasing the business value of information. EMC Symmetrix DMX-3 and DMX-4 systems with Symmetrix Optimizer Virtual LUN technology make data migration a reality without ever disrupting applications.

Virtual LUN technology gives you greater control over information, allowing you to realize its true potential.

References • EMC Solutions Enabler Symmetrix Array Controls CLI Product Guide • Symmetrix Management Console online help


Documents

Symmetrix Optimizer Virtual LUN Technology · PDF fileSymmetrix Optimizer Virtual LUN Technology A Detailed ... overview of data migration strategies and ... EMC Symmetrix® DMX-3