emc symmetrix performance using optimizer

8/12/2019 EMC Symmetrix performance using optimizer

1/37


2/37

Copyright 2003, 2008 EMC Corporation. All rights reserved.

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

THE INFORMATION IN THIS PUBLICATION IS PROVIDED AS IS. EMC CORPORATIONMAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THEINFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIEDWARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Use, copying, and distribution of any EMC software described in this publication requires an applicablesoftware 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 C1062.1

EMC Symmetrix OptimizerA Detailed Review 2


3/37

Table of Contents

Executive summary ............................................................................................5 Introduction.........................................................................................................5

Audience ...................................................................................................................................... 5 What is Symmetrix Optimizer? ..........................................................................5

Demo mode.................................................................................................................................. 6 Supported environments.............................................................................................................. 6 Configuration requirements.......................................................................................................... 7 Dynamic Reallocation Volumes (DRV technology)...................................................................... 7

Interaction with TimeFinder...................................................................................................... 7 Requirement for open mirror position....................................................................................... 7 Requirement for open configuration lock ................................................................................. 7

How does Symmetrix Optimizer work?.............................................................8 Analysis........................................................................................................................................ 8

Performance metrics ................................................................................................................ 8 Modeling service time............................................................................................................... 9 Finding the best swap .............................................................................................................. 9

Swap procedure......................................................................................................................... 10 Mirrored device swap steps.................................................................................................... 10 RAID 5 swap steps................................................................................................................. 11 RAID 6 swap steps................................................................................................................. 12 Legality of swaps.................................................................................................................... 12 Impact of the swap procedure................................................................................................ 14

Symmetrix Optimizer features and best practices.........................................14 Virtual LUN (LUN migration) ...................................................................................................... 14 Swap modes .............................................................................................................................. 16

Automatic/User Approved ...................................................................................................... 16 User-defined swaps................................................................................................................ 17 Rollback.................................................................................................................................. 18 Tips......................................................................................................................................... 18 Setting Rollback from SMC .................................................................................................... 19

Analysis reports ......................................................................................................................... 19 Workload and Initial Analysis Period ......................................................................................... 21

Tips......................................................................................................................................... 22 Setting Workload Analysis Period and Initial Period from SMC............................................. 22

Device Attributes........................................................................................................................ 23 Tip........................................................................................................................................... 23 Setting Device Attributes from SMC....................................................................................... 23

Swap and Performance Time Windows..................................................................................... 24 Tips......................................................................................................................................... 24 Setting Swap and Performance Time Windows from SMC ................................................... 24

Pace and aggressiveness of optimization ................................................................................. 26 Tip........................................................................................................................................... 27 Setting pace and aggressiveness of optimization from SMC................................................. 27

Logs ........................................................................................................................................... 27 Tips......................................................................................................................................... 27 Setting logs from SMC ........................................................................................................... 27

Rule-based analysis................................................................................................................... 28



4/37

Disk rules................................................................................................................................ 28 Device rules............................................................................................................................ 29 Tips......................................................................................................................................... 29 Setting the Device Group and Disk Group Rules from SMC ................................................. 30 Disk Group rules..................................................................................................................... 30

Conclusion ........................................................................................................32

Appendix A: Symmetrix Optimizer and TimeFinder in Enginuity versionsprior to 5568 ......................................................................................................32

Potential interactions.................................................................................................................. 32 Solution sets ........................................................................................................................... 33

Appendix B: Using Optimizer from the CLI ....................................................33 Setting User Approved mode..................................................................................................... 34 Setting performance time windows............................................................................................ 35

Setting swap priority............................................................................................................... 35 Optimizer logs and swap history ............................................................................................ 35 VLUN migration ...................................................................................................................... 36

Appendix C: Troubleshooting..........................................................................37



5/37

Executive summaryEnterprises of all sizes require consistent and predictable access to mission-critical information as thefundamental criteria to achieving business success and competitive edge this means the informationinfrastructure needs to be tuned and optimized at all times with minimal maintenance and intervention.

This white paper provides an in-depth operational description of EMC

Symmetrix

Optimizer as one of afamily of information management software solutions offered by EMC to achieve performance tuning atthe disk device level

IntroductionThis white paper is intended to provide the reader with an in-depth understanding and an under thecovers view of the Symmetrix Optimizer product. The following topics will be covered:

Product overview

Demonstration mode functionality

Supported environments

Configuration

DRVs (dynamic relocation volumes)

TimeFinder technology

Optimizer functional operation

Features and best practices

Troubleshooting

AudienceThis white paper is designed for Technical Sales/Pre-sales and Symmetrix Champions.

What is Symmetrix Optimizer?Symmetrix Optimizer improves array performance by continuously monitoring access patterns andmigrating devices (Symmetrix logical volumes) to achieve balance across the disks in the array. This

process is carried out automatically based on user-defined parameters and is completely transparent to endusers, hosts, and applications in the environment. Migration is performed with constant data availabilityand consistent protection.

Symmetrix Optimizer can be utilized via either the EMC Symmetrix Management Console GUI or CLI,where users can define the following: Symmetrix devices to be optimized Priority of those devices Window of time that profiles the business workload Window of time in which Optimizer is allowed to swap Additional business rules The pace of the Symmetrix Optimizer volume copy mechanism

After being initialized with the user-defined parameters, Symmetrix Optimizer operates totallyautonomously on the Symmetrix service processor to perform the following steps:



6/37

1. Symmetrix Optimizer builds a database of device activity statistics on the Symmetrix back end.

2. Using the data collected, configuration information, and the user-defined parameters, the Optimizeralgorithm identifies busy and idle devices and their locations on the physical drives. The algorithmtries to minimize average disk service time by balancing I/O activity across physical disks by locating

busy devices close to each other on the same disk, and/or by locating busy devices on faster areas of

the disks. This is done by taking into account the speed of the disk, the disk geometry, and the actuatorspeed.

3. Once a solution for load balancing has been developed, the next phase is to carry out the Symmetrixdevice swaps. This is done using established EMC TimeFinder technology, which maintains data

protection and availability. Users can specify if swaps should occur in a completely automatedfashion, or if the user is required to approve Symmetrix device swaps before the action is taken.

4. Once the swap function is complete, Symmetrix Optimizer continues data analysis for the next swap.

D em o m o d eThe demo mode of Symmetrix Optimizer (previously known as the analysis mode ) enables customers to see

the potential Symmetrix performance improvements that Symmetrix Optimizer would make, before theyactually purchase the product. In demo mode, Optimizer fills up a sample database and generates a list ofswaps that would lead to improved back-end Symmetrix performance. It then produces graphical outputcomparing the current performance with the predicted performance if the suggested swap were to beexecuted.

Even though this mode isnt considered an official feature of Symmetrix Optimizer, it is a useful evaluationtool for potential customers of Symmetrix Optimizer.

Demo mode is available through the service processor and, by default, is enabled. There is no customerinterface to enable demo mode or retrieve its outputthese are both service-processor-resident capabilitiesand, as a result, require a CE. Because of this, demo mode should not be used once Optimizer has beenpurchased and implemented . If a customer has purchased Optimizer but does not want to allow it tomake swaps, the user approval mode should be used instead of demo mode.

Suppor ted env i ronm entsSymmetrix Optimizer consists of two major components:

The Optimizer processing engine runs continuously on the Symmetrix service processor and collectsthe statistics, performs the analysis, executes, and monitors the configuration changes. Thiscomponent is associated with the version of Symmetrix Enginuity software running on theSymmetrix array. Versions of the Optimizer engine (with different functionality) are referred to asdifferent revs of Optimizer (Rev5 5x71, Rev6 5772 and Rev7 5773).

The client user controls for Optimizer parameters. This client can be the EMC SMC, EMCControlCenter GUI, or SYMCLI command line interface.

Optimizer is available for Symmetrix arrays running Enginuity software versions 5x66 and later. Refer tothe EMC Support Matrix (found on the Powerlink website) for details on minimum versions of Enginuitysoftware release levels required, along with the compatible user control interfaces for each revision ofOptimizer and the required service processor versions.

Since Symmetrix Optimizer operates on Symmetrix devices and physical disks, there are no compatibilityrequirements at the host or application level. However, since NCR Teradata operates by spreading activityacross volumes, Symmetrix Optimizer is generally not sold into this environment.



7/37

Symmetrix Optimizer can optimize all open system and mainframe RAID 1 (mirrored), RAID 5 (3+1 and7+1), RAID 6 (6+2 and 14+2), and RDF-protected volumes in an array. Optimizer does not work withvolumes configured for use with the AS/400 operating system. Optimizer does not consider businesscontinuance volumes (BCVs), dynamic reallocation volumes (DRVs), SFS devices, target of SNAPdevices, thin devices, and thin data pools for swapping (refer to the Legality of swaps section on page 12 for a more complete list).

Conf igura t ion requ i rementsIn order for Symmetrix Optimizer to function, DRVs must first be configured and Symmetrix Optimizerenabled by EMC from the service processor. It is important to understand Optimizers requirement of anopen mirror position.

Dynam ic Real locat ion Volum es (DRV techn olog y)The DRV is a non-user-addressable logical volume used by Symmetrix Optimizer to temporarily holdcustomer data while reconfiguration (on logical volume granularity) is executed. Data is available and

protected during the reconfiguration process.

As a minimum, two DRVs must be configured for each size and emulation of volume to be swapped by

Optimizer. For example, for Optimizer to swap 4 GB open-system volumes, then two 4 GB open systemDRVs must be configured. If more than one simultaneous swap is desired, then additional DRVs areneeded (two for each swap). If there are volumes of mixed size or emulation within the same Symmetrixframe, then DRVs are required for each size and type to be swapped.

RAID 6 devices or devices with at least three local copies of data do not require DRVs for swapping.

Interaction with TimeFinderWith the introduction of the features for concurrent BCVs and independent splits in Enginuity 5568.49.18,the direct conflicts between TimeFinder and Optimizer have been eliminated. In earlier versions ofEnginuity, there was a potential for either Optimizer or TimeFinder to fail in its intended task if bothattempted to operate on the same volume at the same time. For specifics on this interaction in Enginuity 66and 67 and how to avoid the potential conflict, refer to Appendix A: Symmetrix Optimizer andTimeFinder in Enginuity versions prior to 5568 on page 32.

Requirement for open mirror positionOptimizer does have a requirement for an open mirror position to be able to perform a swap. This limitationis the four mirror slots for a volume on the Symmetrix system. So, for example, if a RAID 1 device alreadyhas two BCVs established (that is, mmBB), then if Optimizer wants to swap this device it cannot get amirror slot for the DRV. If Optimizer does not have a mirror slot available, then it will drop the swap andrerun the analysis. If Optimizer is in Rollback, Manual, or User-Approved mode, then Optimizer will retrya number of times and eventually stop an error if a mirror slot does not become available.

Requirement for open configuration lockIn order for Optimizer to perform a swap or a migration, it needs to hold the configuration lock. Theconfiguration lock is an exclusive lock on the Symmetrix system for performing configuration changes.This lock prevents multiple applications from changing the Symmetrix configuration at the same time. Ifanother application (such as SDR) holds the configuration lock when Optimizer wants to create a swap,then Optimizer will behave as previously stated (no open mirror position). Optimizer will hold theconfiguration lock for the duration of the swap, so other applications will not have the ability to performconfiguration changes during this time.



8/37

How does Symmetrix Optimizer work?The analysis methodology and the swap procedure are the core technology and the two main componentsof the Symmetrix Optimizer solution. The following sections provide a brief description of them.

Analys i sWhen Symmetrix Optimizer evaluates performance statistics, it evaluates potential volume swaps based onhow well they would improve overall performance. This analysis is based on minimizing disk service time(rotational latency plus seek time plus transfer time). Symmetrix Optimizer uses three strategies whendetermining which swaps to make:

First, swapping highly active volumes to disks with lower activity evens out the load across the physical drives in the Symmetrix system. This decreases the contention on the individual physicaldisks, improving the performance of both highly active volumes and low-activity volumes.

Second, swaps that relocate highly active volumes so that they are closer together on the physical diskwill decrease the seek distance for I/Os to these volumes. When Optimizer swaps volumes, it will tryto achieve this type of configuration since it decreases the overall I/O service time.

Finally, Optimizer tries to swap highly active volumes on the outer zones of the disk. This is becausevolumes located on the outer zones of the disk have faster transfer speeds.

Symmetrix Optimizers algorithm uses detailed disk performance information that takes into accountseveral drive characteristics such as those gig-to-gig seek times, Zone Bit Recording, and bandwidth data.

Figure 1. Optimization strategies

By default, the goal of the Symmetrix Optimizer is to minimize the average service time of the Symmetrix disks.Optimizer Revision 4 introduced a new mode: Hot spot analysis. In this mode, the target function was changed tolower the peak service times rather than the average service times.

Performance metricsOptimizer only looks at back-end activity; it uses the back-end logical volume statistics obtained through aunique Optimizer system call. The metrics used are:

DA logical volumes reads DA logical volumes writes Logical volume prefetch

DA logical volumes blocks read DA logical volumes blocks written

While modeling the disk service time, different weights are assigned to read, write, and prefetch activity.The assumption is that since writes are done as a background process, they are done in sequence and henceare more efficient. Optimizer does not try to follow DMSP policies; instead, it assumes that reads areequally spread among all the device mirrors, and all mirrors do all writes.



9/37


10/37

EMC allows more than 128 hypers per disk; finding a swap that improves service time by 10 percent ormore on these systems is very rare.

Since using a percentage of improvement as swap goodness criteria is not applicable anymore, Optimizerhad to adapt a different method (M0) that deals better with the many hypers contribute smaller chunks

problem. M0 is defined as the best you could possibly get from a swap. Each disk in the system isassigned an M0 designation, which is defined as the minimum service time a disk can get by replacing one

of its hypers by a null hyper (a hyper that does no I/Os to the disk). When analyzing a swap, Optimizerchecks how close the new-modeled service time is to the disks M0; the closer to M0, the better the swapis. Usually, two RAID groups are affected by a single swap; the busier disks service time is expected to godown while the other disks service time is expected to go up. In addition to the M0, the Optimizer alsoensures that the new maximum of service times is less than the old one.

Swap procedureThe swap procedure relies on the Symmetrix TimeFinder technology and uses DRVs as temporary mirrors.The following section describes the four swap steps when dealing with mirrored devices swaps. In the caseof three mirror devices or RAID 6 devices the swap procedure does not require a DRV.

Mirrored device swap stepsHypervolumes are swapped using a four-step process. In order to swap two hypervolumes, thehypervolumes must be the same size, the same emulation, and, based on the architecture, on the samesystem bus or in the same power zone in the Symmetrix DMX architecture in versions prior to 5772. Atleast two DRVs must be configured per swap. With Symmetrix Optimizer 5.1.1, up to eight simultaneousswaps can happen at one time, however, the recommended number of simultaneous swaps is four.

Step 1: Identify volumes to swapSymmetrix Optimizer identifies a pair of hypervolumes to swap based on recognizable patterns ofhypervolume activity and criteria. Assume the red volumes have high activity and the blue volumes havelow activity.

Figure 2. Identify volumes to swap

Step 2: Copy a volume to DRVSymmetrix Optimizer swap commands are passed to SymmWin, which will assign one DRV (DRV 1) as athird mirror for hypervolume A. A second DRV (DRV 2) will be assigned as a third mirror forhypervolume B. All tracks on the third mirror are marked invalid. Tracks are copied from the valid mirrorsto the two DRVs. After the DRVs are synchronized, the two original swap physical mirrors are marked

Not Ready (volume A and volume B) and their attributes are swapped ( Figure 3 ). Both hypervolumes stillhave two (or more) physical mirrors. Host activity to the hypervolumes is now directed to DRVs and theother mirror.



11/37

Figure 3. Copy a volume to DRV

Step 3: Copy DRV to a new locationThe data on the DRVs is now copied to the new location. After the attributes of the original hypervolumesare swapped, SymmWin copies the tracks from the valid mirrors to the two new mirrors and then makes theoriginal hypervolumes ready ( Figure 4 ). This is similar to a BCV restore.

Figure 4. Copy DRVs to new locations

Step 4: DRVs are splitThe final step is to split the DRVs from their standard and mirror hypervolumes once synchronization iscomplete ( Figure 5 ). The balance of the drives is improved, and the DRVs are now available for the nextswap.

Figure 5. DRVs are split

Note: Swap of three mirror devices does not require a DRV.

RAID 5 swap stepsRAID 5 device swaps require a DRV. The DRV should be of the same size of the DATA portion of theRAID 5 device and should follow the same configuration rules as DRVs that are used to swap mirroreddevices.

Step 1: Identify volumes to swapThis is the same as for mirrored devices.

Step 2: Copy DATA of a volume to DRVThis is the same as for mirrored devices, but only the DATA portion of the RAID 5 device is copied to theDRV. The parity data is not copied.



12/37

Step 3: Copy DRV to a new locationThe data on the DRVs is now copied to the new location. Each RAID 5 member is copied and constructedseparately from the other members and the DRV. After each member is fully constructed the configurationis changed, the system is IMLed and only then the system continues with the next member. Throughoutthe whole process all RAID 5 members (except one) and the DRV are available and ready.

Step 4: DRVs are splitThis is the same as for mirrored devices.

RAID 6 swap stepsRAID 6 device swaps do not require a DRV.

Step 1: Identify volumes to swapThis is the same as for mirrored devices.

Step 2: Copy DATA to a new locationEach RAID 6 member is copied and constructed separately from the other members. After each member isfully constructed the configuration is changed, the system is IMLed and only then the system continueswith the next member. Throughout the whole process all RAID 6 members (except one) are available andready.

Legality of swapsAs a rule, Optimizer will never suggest a swap that conflicts with configuration rules as defined by themicrocode, SymmWin, or the configuration groups. For the Symmetrix 3000, 4000, and 8000 hardwarefamilies, all configuration rules are static. However, for the Symmetrix DMX and RMS families, someconfiguration rules are static and some are more dynamic and defined in relative manner where anOptimizer swap can improve or maintain the protection level but will never decrease the protection level.(Exceptions for this might be a rollback session, where the user wants to undo a swap.)

67/68 code (Symmetrix 3000, 4000, and 8000 families)

For Symmetrix 3000, 4000, and 8000 hardware families, the following rules apply: Swappable devices

RAID 1 (mirrored volumes) RDF devices with two local copies (default, can be controlled from SP) Same size and emulation

Not swappable devices. The following devices are not swappable: Parity RAID (parity and data) CKD Stripe (RAID 1/0) BCV, DRV SFS

WORM AS400, ICOS, ICL Standard, unprotected volumes (default, can be controlled from SP)

Other configuration restrictions: Same disk Two mirrors of the same device should never reside on the same disk (for example,

1a:C0). X/Y bus Two mirrors of the same RAID 1 device should never reside on the same memory bus

(for example, 1a with 3a).



13/37

Dual-Initiator Two mirrors of the same RAID 1 device should never reside on the same DA anddual-initiator pair (for example, 1a with 2a).

69/70/5671 code (Symmetrix DMX and RMS)Configuration rules for the Symmetrix DMX and RMS families are relative in manner. Optimizer canimprove or maintain protection, but never decrease the level of protection. However, some restrictions

should always be followed. Swappable devices

RAID 1 (mirrored volumes) RAID 5 RDF devices with two local copies (default, can be controlled from SP) Same size and emulation

Not swappable devices. The following devices are not swappable: Parity RAID (parity and data) CKD Stripe (RAID 1/0) BCV, DRV SFS WORM AS400, ICOS, ICL Saved and virtual snap devices Standard, unprotected volumes (default, can be controlled from SP) Targets of snap sessions

Other configuration restrictions: Same disk Two mirrors of the same device should never reside on the same disk (for example,

1a:C0 new syntax 1a:00). Same port Two mirrors of the same device should never reside on the same port (for example,

1a:C new syntax 1a:0).

Same loop

All mirrors of the same RAID 1 device should never reside on the same disk loop(for example, 1a:C with 16a:C new syntax: 1a:0 with 16a:0). (This is not applicable to RMS.) Power zones All mirrors of the same RAID 1 device should never reside on the same power

zone. (Applicable to Panther and Rhino only.) Same DA All mirrors of the same RAID 1 device should not reside on the same DA (CPU) (for

example, 1a). Same slot All mirrors of the same RAID 1 device should not reside on the same director (slot)

(for example, 1a with 1b). Dual-Initiator All mirrors of the same RAID 1 device should not reside on the same dual-

initiator pair (for example, 1a with 16a). (This is not applicable to RMS.)

5771/72/73 code (Symmetrix DMX and RMS)

Configuration rules for the Symmetrix DMX and RMS families are relative in manner. Optimizer canimprove or maintain protection, but never decrease the level of protection. However, some restrictionsshould always be followed.

Swappable devices RAID 1 (mirrored volumes) RAID 5 RAID 6 (72+) RDF devices with two local copies (default, can be controlled from SP)



14/37

Same size and emulation Not swappable devices. The following devices are not swappable:

CKD Stripe (RAID 1/0) BCV, DRV SFS

WORM AS400, ICOS, ICL Saved and virtual snap devices Standard, unprotected volumes (default, can be controlled from SP) Targets of snap sessions Thin provision data pools

Other configuration restrictions: Affinity groups All members of a RAID 5, RAID 6 or RAID 1 device should reside on the same

affinity group. These are groups of disks (16, 8, 4 or 2 disks in a group) also called RAID groups. Same disk Two mirrors of the same device should never reside on the same disk (for example,

1a:C0 new syntax 1a:00).

Same port Two mirrors of the same device should never reside on the same port (for example,1a:C new syntax 1a:0).

Same loop All mirrors of the same RAID 1 device should never reside on the same disk loop(for example, 1a:C with 16a:C new syntax 1a:0 with 16a:0).

Same DA All mirrors of the same RAID 1 device should not reside on the same DA (CPU) (forexample, 1a).

Same slot All mirrors of the same RAID 1 device should not reside on the same director (slot)(for example, 1a with 1b).

Dual-Initiator All mirrors of the same RAID 1 device should not reside on the same dual-initiator pair (for example, 1a with 16a).

Impact of the swap procedureEach swap performed by Optimizer is the equivalent of two TimeFinder operations. In order to minimizethe effect of the swap procedure on the overall Symmetrix performance, the Symmetrix Optimizer will notinclude the same spindle twice in one swap group. In addition, the customer, using QOS controls, can setlower BCV priority for the STDs to be swapped, and can also plan the swap activities, using the TimeWindow feature, to occur on idle business time.

Symmetrix Optimizer features and best practices

Virtual LUN (LUN m igrat ion)Virtual LUN technology is an enhancement to the Symmetrix Optimizer product that enables transparent,non-disruptive data mobility among storage tiers within the same storage system with devices of the sameRAID protection scheme. Virtual LUN technology is supported for both open system and mainframe

platforms and includes support for metavolumes. All swappable devices can be part of the LUN migration.

Virtual LUN technology provides users the ability to move data between high-performance disks and high-capacity disks, or to populate newly added disk drives. This delivers tiered storage capabilities within asingle Symmetrix array.

The white paper EMC Symmetrix Optimizer Virtual LUN Technology A Detailed Review describes theconcepts and user interface of the VLUN migration feature, and in this document we will highlight a fewtechnical subjects relevant to the new functionality.



15/37


16/37

Configuration change priorities The Optimizer can do migrations that were defined as rules, swaps thatare found by the Optimizer analysis engine in automatic mode, and manual swaps and migrations. The newOptimizer has a priority mechanism to determine which configuration change to invoke when an inclusionswap time window becomes active. Based on this logic, rules of meta migrations get the highest priorityonce they started; this is in order to accelerate the migration and minimize the time that the metadevicerules are broken (all members on same speed disks). When there is no meta migration in progress then thescheduler will use the rules priorities while the automatic swap suggestions are considered as normal

priority,

S w ap m o d e sBy default, Optimizer runs in Automatic mode, meaning that when Optimizer determines a swap list, it willschedule the swap to occur at the next available swap time window. (Refer to the section Swap andPerformance Time Windows on page 24.) However, the user may choose to monitor the swaps before theystart by selecting User Approved mode. In User Approved mode, the Optimizer displays the swap list andallows the user to either approve or cancel the swap list via the swap wizard.

The swap wizard also provides other modes of operation: User Defined (allows the user to manually defineswaps, migrations) and Rollback (allows the user to undo all swaps done from a specific date and time).

Automatic/User ApprovedSwitching between Automatic and User Approved mode is done through the Optimizer dialog box(Figure 6 ), with the available swap modes of Automatic and User Approved. If Automatic is selected,Optimizer will perform swaps without user confirmation. If User Approved is selected, Optimizer

prompts for approval before each swap session.

Figure 6. Optimizer parameter settings tabs



17/37

User-defined swapsThe swap wizard provides an option to define, verify, and schedule user-defined swaps. This featureallows the user to manually create and schedule swaps and provides a vehicle to:

Undo specific swaps. Quickly swap highly active devices to newly attached disks. Edit an Optimizer suggested list of swaps.

Note the following for user-defined swaps:

A swap can be performed with a properly configured, but inactive device. There is no requirement that both logical devices be currently processing I/O.

The Optimizer is used as a verifier and as a swap engine. It is the users responsibility to define swapsthat do not have a negative impact on the overall performance of the Symmetrix back end. TheOptimizer uses the same swap legality checks when verifying user-defined swaps as it does in otherswap modes.

Users can either create the list of swaps from scratch or use the Optimizer suggested swap list as the baseline.

Creating a list of swaps from scratchTo start a list from scratch, follow these steps:

1. Select the first hyper and click Add .

2. Select a second hyper from the list displayed in Hyper 2, and click Add to add the pair to the swap list.Figure 7 illustrates this feature.



18/37

Figure 7. Swap Wizard: Create a user-defined swap list

Using the Optimizer suggested swap listTo start a list from the Optimizer suggested swap list, follow these steps:

1. Click Suggest to retrieve the swap list from the Optimizer service processor. (The Optimizer had to berunning in User Approved mode first in order to have a list pending.) If no list is available, a message

box is displayed.

2. Once the user-defined swaps are chosen, click Next or Finish to validate the swap list.

3. Proceed to the review dialog box, and schedule the swap to execute according to Optimizer policy (torun at the next available swap time window) or at a specific time and date.

RollbackUse the Rollback mode from the swap wizard to undo swaps that conflict with your business rules. Therollback feature is an all or nothing feature. Optimizer reverses all swaps by going backward from the

present to a selected earlier time and undoing each and every swap. Use the User Defined mode to undospecific swaps.

Tips Use User Defined mode rather than Rollback to undo specific swaps. Rollback swaps can be scheduled for execution according to Optimizer policy.



19/37

Rollback swaps can be stopped only between swap groups. Each swap group is an atomic session thatcannot be interrupted.

Setting Rollback from SMCSelect the Swap Management tab from the Optimizer main window to start the swap wizard. Then, selectRollback and click Next . View the swap history to determine the exact date and time to roll back to. Allswaps that occurred on the Symmetrix system between the start date and the current time will be reversedonce the rollback session is approved and scheduled.

Figure 8. Swap Wizard: Rollback

To approve the swap list, select when Optimizer should execute the swap list. If you select According toOptimizer Policy in the Analyze performance and Schedule dialog box (Wizard, step 3), the swap list will

be executed according to the swap time windows you have set. Optionally, you may specify a date andtime to execute the swap list. This option will override any swap time window that you have defined.

The Swap Status tab allows you to monitor Optimizer as it steps through each of the swaps in the list.This tab is available only when a swap is in progress. It also provides a graphical representation ofOptimizers progress through the swap list.

Analys i s r epor t sSelect the Analyze button in the Analyze performance and Schedule dialog box to view the collection ofcharts and tables that summarize Optimizers analysis of disk performance. The charts and tables aredisplayed within the default browser available on your client workstation. The left panel lists the timewindows when the swap is executed, while the right panel offers a tabbed display of the following threecharts: Affected Disks, Top 20 Disks, and All Disks. Figure 10 shows an example of the affected physicaldisks.



20/37

The Y axis is the Estimated Disk Activity; it is the average calculated disk service time divided by theduration and normalized to a 0 to 100 scale. In extreme cases, the estimated disk activity might be higherthan 100; this is due to some assumptions that the Optimizer algorithm takes such as the randomdistribution, independent I/Os, and interleave mirror policy to serve reads.

Figure 9. Analyze Performance and Schedule



21/37

Figure 10. Analysis

Worklo ad and Ini t ial Analysis Per iod

The Workload Analysis Period ( Figure 11 ) specifies the amount of workload sampling that Optimizershould maintain for sample analysis. The minimum is one hour and the maximum is three weeks. Thedefault is one week.

The Initial Period ( Figure 11 ) specifies the minimum amount of workload sampling that Optimizer shouldcomplete before analyzing the samples for the first time. This parameter exists in a case where you do notwant to wait until the entire workload period has elapsed before Optimizer commences its analysis andswap activity. The minimum is one hour and the maximum is the workload analysis period, which is thedefault.



22/37

Tips The workload analysis period should match your business cycle. For most organizations, one week

represents a complete business cycle. By default, Optimizer uses a 10-minute interval between data collections. This interval was proved to

be a reasonable option taking into account the overhead on the Symmetrix system and the overhead of processing too many data samples on the service processor with the Optimizer engine. If you choose alonger workload analysis period (say, three weeks) Optimizer will change the data collection intervalto 30 minutes. This might affect the quality of analysis because short bursts of activity and correlation

between volumes might be missed due to the longer collection period. Optimizer runs the analysis process only if there is good enough coverage of the analysis period. (The

oldest sample is older than the initial period, and the database contains more than 50 percent of theexpected time samples.)

Setting Workload Analysis Period and Initial Period from SMCThe Parameter tab of the Optimizer dialog box provides both status information and configurationcapabilities for Optimizer. To change parameters, and have them recognized by the service processor,follow these steps:

1. Stop Optimizer.

2. In the Workload Analysis Settings field, enter the new parameters for the Workload Analysis Period,or enter new parameters for the Initial Period.

3. Click Apply .

4. Restart Optimizer.

Figure 11. Setting new Workload Analysis Settings



23/37

Device At t r ibu tesThe Device Attributes dialog box allows you to assign priority attributes to specific logical devices. Theseattributes assist Optimizer during sample analysis. Defined attributes are:

High Priority Assign this device the highest priority because it contains crucial data. Optimizerattempts to achieve the best performance for this device without sacrificing the performance of other

devices in this high-priority group. Normal Priority This device is eligible for swap, but assign it a normal priority. No Swap Do not swap.

Figure 12. Device Attributes

TipDo not define too many devices as high priority because that will eliminate optimization options. As a ruleof thumb, the number of high priority devices should not exceed 10 percent of the number of disks.

Setting Device Attributes from SMCTo set logical device priority, follow these steps and refer to Figure 12 :

1. Select one or more logical device using the device filter.

2. Click one of the priority buttons to set the priority for the selected rows.

3. Click OK to save the changes.



24/37

Swap and Per fo rm ance Time Window sSymmetrix Optimizer utilizes time windows to schedule swaps and to indicate what time samples are to beused for the analysis process. By default, Optimizer will include all samples in its analysis. Note that thedefault swap time window is set to exclude ; no swaps will be performed until the swap time window ischanged.

Use the performance time windows to identify your business cycle and to specify date and time ranges(past or future) when samples will be included in or excluded from the Symmetrix Optimizer analysis. Bydefault, all performance information is used, due to a default time window.

Use the swap time windows to specify date and time ranges when swaps are allowed or not allowed to start.The Symmetrix Optimizer will never start a swap session less than 30 minutes before the end of aninclusion swap time window; however, a swap that has started may continue beyond the specified timewindow.

Use the swap time windows to carefully plan swap sessions and to minimize impact on performance ofcritical workloads. Although the swap process runs in low priority, it might introduce some overhead on theSymmetrix back end. Reducing the maximum number of simultaneous swaps and using the quality ofservice (QoS) copy-pacing feature are other ways to minimize the overhead of Optimizer swaps.

Time windows are hierarchical in nature and can be either periodic or non-periodic. If multiple time

windows have time ranges that overlap one another, the higher-listed time window will override the others.Therefore, the order of time windows in the list resolves conflicts between overlapping time windows;conflict resolution only applies to time windows of the same type.

Tips Swap and performance time windows both have one default time window. The default time window

can be set to either inclusion or exclusion. Use this feature to simplify the time window definitions. When in SMC, use the client local time to set time windows. Conversion of time zone is done

automatically by the Optimizer server. The Symmetrix Optimizer collects and saves performance data regardless of the performance time

window definitions; these definitions are only relevant for the analysis process. As a result, analysisdata is always available, and there is no need to collect new statistics when a new time window isdefined.

Time windows that span over the day in which daylight savings time is defined may be off by onehour. The best practice is to define two separate time windowsone for winter and one for summer.

Setting Swap and Performance Time Windows from SMCThe lower table in Figure 12 is an editable summary of either the Performance or Swap Time Windows.



25/37

Figure 13. Time Windows

The pull-down menu on the left side controls the type of list. The position of the time windows in the tableassigns them a priority, with the first row having the highest priority. If multiple time windows have timeranges that overlap each other, the higher-listed time window overrides the others. Therefore, the order oftime windows in the list resolves conflicts between overlapping time windows; conflict resolution onlyapplies to time windows of the same type.

To add a new time window:

1. Select Swap Time Window or Performance Time Window from the pull-down menu on the left sideof the Time Windows dialog box ( Figure 13 ).

2. Click New . The Optimizer - Select a time window for performance dialog box appears ( Figure 14 ).

3. Specify the values you require for the new time window.

4. Click OK .

The new time window is now added to the lower table list in the Time Windows dialog box.



26/37

Figure 14. Performance Time Settings

To edit an existing time window, follow these steps:

1. Select a target row in the lower table of the Time Windows dialog box.

2. Click Edit The Optimizer - Select a period dialog box appears, with the existing values displayed.

3. Edit the values you need to change.

4. Click OK . The revised time window values are now displayed in the lower table list of the TimeWindows dialog box.

Pace and aggress iveness of opt im izat ionThe pace and aggressiveness of optimization can be controlled using two parameters:

Maximum number of swaps per day Maximum number of simultaneous swapsThe maximum number of swaps per day is a way to limit swap activity on the array. This might be usedwhen Optimizer is in Automatic mode and the user would like to be more conservative with how quicklyOptimizer can make changes in the environment. At the upper limit, swaps are naturally limited by theamount of time swaps take to complete. For example, if only one swap pair occurs at a time, and theaverage time per swap pair is 2 hours, then there will be no more than 24 moves (12 swap pairs) on averageduring a day. On the other hand, the user can limit the number of swaps to four pairs per day, for example(by setting the maximum number of swaps per day to 8). This allows the user to monitor the impact of the



27/37

swaps, and allows more time for Optimizer to take the resulting modified workload into consideration forthe calculation of the next swap pair.

The maximum number of simultaneous swaps allows Optimizer to perform more than one swap at a time.For each swap pair that may occur simultaneously, the system must be configured with a pair of DRVdevices for each size and emulation of volume to be swapped. So, if the user wants four swaps (two pairs)to occur at the same time for 8 GB volumes, then four DRVs (8 GB in size) must be configured. By

increasing the maximum number of simultaneous swaps, the system can be optimized much more rapidly.

TipEight simultaneous moves (four swaps) proved to be a reasonable option. Since swaps are executed as low

priority tasks, the performance impact of multiple swaps is relatively low.

Setting pace and aggressiveness of optimization from SMCThe maximum number of swaps per day and the maximum number of simultaneous swaps can both be setin the Parameters tab of the Optimizer dialog box in the Swap Settings area. In order to changeOptimizer parameters, Optimizer must first be stopped.

L o g sIt is possible to retrieve Optimizers activity or error logs. These logs are useful if you want to view anOptimizer error or retrieve past or current state information about Optimizer. The log data is kept on theSymmetrix service processor.

Tips Optimizer keeps log data in memory, not files. You can use the Export icon in the Log tab of the

Optimize r dialog box to save the current log as a file. Times specified in the log data are in service processor time, with a reference to GMT in parentheses.

Setting logs from SMCThe Log tab ( Figure 15 ) of the Optimizer dialog box lets you retrieve current and past state information onOptimizer activities and errors. To view log information, select either All Activity or Error Log . Specifythe beginning of the time period in one of the following ways:

Use the pull-down menu to specify a date and time. Select Use Optimizer launch as starting date . Select Use oldest entry as starting date .

Specify the end of the time period by using the pull-down menu or by selecting Ignore ending date .Figure 15 illustrates this feature.



28/37

Figure 15. Optimizer Logs

Click Get Log to display the log in the lower section of the dialog box, or click Stop to terminate theretrieval process.

Rule-based analys isThe rule-based analysis feature is aimed to fill in the gaps in the knowledge of the environment ofSymmetrix Optimizer. The Symmetrix Optimizer algorithm runs on the service processor and does nothave access to host information such as host striping, database files, data and indices, or applications. Thisfeature allows SMC and EMC ControlCenter users and third-party software tools and products to providethe relevant information to the Symmetrix Optimizer and to have better control on the optimization process.

The feature uses device and disk groups in order to define the scope of the rules. These groups may beeither EMC ControlCenter groups or Optimizer groups.

Users can specify a set of rules. The Symmetrix Optimizer analysis process will generate moves satisfyingthese rules. The set of rules can be divided into three types: disk rules, device rules and migration rules.

Disk rulesThis section discusses the following disk rules:

Disk pool

Disk exclude Intra disk

Disk poolAll disks in the Symmetrix system are partitioned into several pools. Moves are only allowed between diskswithin the same pool. The user may direct the Symmetrix Optimizer to optimize only a certain disk pooland ignore the others, or to allocate a higher priority to certain pools.



29/37

Examples/use cases: In an xSP environment, the service provider can divide the Symmetrix disks into pools, and then assign

each pool to a different customer. The service provider can then differentiate higher levels of service by assigning higher priority to specific pools.

In a corporate or multi-division environment, the storage manager can divide and provide differentlevels of service to different departments.

Disk excludeA user may choose to exclude groups of disks from the optimization process.

Example/use case:In an xSP environment, the system administrator is satisfied with the performance of a group of disks andwants to maintain the same configuration for this group.

In tier storage the system administrator does not want to spend Optimizer cycles on capacity and low priority storage.

Intra diskThis feature specifies that only intra-disk moves are allowed for a group of disks provided by the user.

Even though the benefits of load balancing cannot be achieved on these disks, there can still beimprovement in performance obtained by reducing seek time and transfer time. This rule is useful inextreme cases where inter-disk moves are limited.

Example/use case:For Symmetrix systems where striping is heavily used, any inter-disk move may result in two or moredevices from the same stripe group residing on the same disk and reducing performance. By performingonly intra-disk moves on the disks with striped volumes, this can be avoided .

Device rulesVolume avoidance Given a device group for volume avoidance, the Symmetrix Optimizer will notsuggest moves that will place two or more volumes in the device group on the same disk.

Examples/use cases: A DB administrator may have some information stored in several volumes. Even though this

information is not accessed most of the time, when it is needed, it is important that the information isaccessed quickly. These volumes should not be situated on the same disk by any move. This can beachieved by creating them as a list for avoidance.

Idle metavolumes. Placing any of two metavolume members on the same disk may degrade performance. If the meta is active, Optimizer probably would not put any two members on one disk, but in many cases metavolumes are defined and not used for a while. During these idle times,Optimizer may swap these volumes and may locate them on the same disk, so device avoidance can beused in order to avoid such a scenario.

Tips Do not divide the Symmetrix disks into too many pools. Too many restrictions may paralyze the

Optimizer from finding the optimum back-end layout. Use device avoidance whenever you define new metavolumes or highly correlated volumes that will

only be used later. Idle volumes may be used as target volumes for swaps and become bottleneckswhen they are finally used.



30/37

Setting the Device Group and Disk Group Rules from SMCTo change rules parameters, and have them recognized by the service processor, follow these steps:

1. Stop Optimizer.

2. Edit the parameters.

3. Click Apply .

4. Restart Optimizer.

You can create new rules or modify existing rules by clicking on New or Edit in the Groups & Rules tab ofthe Optimizer dialog box ( Figure 16 ).

Figure 16. Groups & Rules tab

Disk Group rulesAfter you click the Groups button in the Groups & Rules tab, the Groups dialog box appears. You can usethe dialog box to create new Optimizer groups, edit the name or membership of an existing group, or deletean existing group.



31/37

Figure 17. Create a new Disk Rule

SMC and SYMAPI groups can be added into the displayed tree by dragging SYMAPI groups into thedialog box. This action causes Optimizer to make a copy of those groups. Any operations that are

performed, such as adding or deleting members, are performed on the Optimizer copies and have no impacton the original group attributes.

Figure 18. Define Disk Group Members



32/37

ConclusionThe in-depth perspective of this white paper should have provided the reader with sufficient understandingand the required knowledge to describe the components and technologies involved with SymmetrixOptimizer. The setup and configurations screens are particularly useful to help guide the reader through thevarious configuration scenarios and the required customization based on user needs.

Finally, and most important, the reader should also appreciate how Symmetrix Optimizer providessignificant benefit to customers enterprises by enhancing the predictability of mission-critical information

performance.

Appendix A: Symmetrix Optimizer and TimeFinder inEnginuity versions prior to 5568Optimizer and TimeFinder both use the Symmetrix feature of dynamic mirroring. With this feature, aspecial volume like the BCV or DRV can become a mirror copy of a Symmetrix volume. In Enginuityrevisions before 5x68xxxxx, there are potential interactions between BCVs and DRVs due to the rules ofdynamic mirroring. With careful setup, TimeFinder and Optimizer can be used successfully with thesecode revisions. If the customers TimeFinder environment is complex, it is best to upgrade to release

5x68xx of the Enginuity microcode.Unlike the DRV, a BCV has additional attributes that allow it to independently support host applicationsand processes. It may be configured as a single mirror, a locally mirrored device, or an SRDF source (R1)device. A BCV device can be RAID 1 or RDF protected, but it cannot be RAID-S protected.

The Optimizers DRV differs from a TimeFinder BCV in that it cannot be connected to a host, and it has noneed for mirror protection.

Potent ia l in teract ionsScenario 1: TimeFinders BCV is synchronized with a volume that Optimizer wants to swap.

If a BCV is already established to the volume selected by Optimizer to be swapped, Optimizer will reject

that swap pick and make the next best swap pairing. Optimizer will check for a significant performanceimprovement before doing a swap. The final swap pick will be sent to SymmWin for swapping. This behavior benefits the performance of the Symmetrix system, and does not present a problem.

But, if the volume that comes up at the top of the swap list is always paired with a BCV during theOptimizer swap window, Optimizer will not be able to correct the performance issue. The Optimizer swapwindow should not align exactly with the window for establishing BCVs.

Remember that a user may leave the BCV established to the STD volume for a long period of time. If thisis the case, there is a high probability the Optimizers swap selection will be affected by this interactionscenario. The interaction can be eliminated by implementing one of the two solutions listed in the nextsection, Solution sets .

Scenario 2: Optimizer is swapping a volume TimeFinder wants.

If Optimizer is swapping a volume that TimeFinder attempts to establish a BCV with, the TimeFinderaction will fail and give a return code error. The script needs to check the return code and one of thefollowing solutions is needed to correct the error.

The time of the Optimizer swap is approximately twice the length of time is takes to establish a BCV to astandard. This is a relatively short period. The probability of this interaction scenario is small. But theconsequence to TimeFinder can be great, and every effort should be made to avoid this interaction. Again,the interaction can be eliminated by implementing one of the two solutions listed in the next section.



33/37

Solution setsTo ensure no interaction between Optimizer and TimeFinder, the customer can take one of the followingsteps.

Solution 1: Exclude all the standard volumes that will be involved with TimeFinder so the Optimizer cannot swap them. This is done by marking the logical volume attributes for this set of volumes to no swap. This will eliminate all the interaction scenarios. Optimizer will swap the remaining volumes to get to anoptimal configuration in the Symmetrix system. This may prevent Optimizer from providing the best-

performing configuration.

This is recommended when TimeFinders usage is limited to a set number of volumes or is not controlled by scripts.

Solution 2: Separate the TimeFinder activity from the Optimizer activity. Scripts or jobs controlling theTimeFinder activity should be set to complete prior to Optimizers swap time zone. Additionally, theOptimizer swap time zones should be set to complete prior to TimeFinder activity taking place. Thisshould separate the dual-copy sessions, blocking the possibility of the conflicts. However, it is possiblethat an Optimizer swap will be initiated during a swap time zone, but not complete until some time after thetime zone has ended. Therefore, it is important for TimeFinder scripts to gracefully handle TimeFinderBCV establish and incremental reestablish command failuresdue to Optimizer still being in the processof swapping volumes (script needs to wait for swap to complete, then attempt the establish). In 5X65, thescripts also need to handle incremental reestablish command failuresdue to Optimizer having previouslyswapped the primary volume (script needs to attempt a full establish).

Appendix B: Using Optimizer from the CLITo start and stop the Optimizer process on the Symmetrix service processor, use the symoptmz enable and symoptmz disable commands. Once disabled, the Optimizer process on the Symmetrix service

processor will still listen for Optimizer clients (SMC, EMC ControlCenter or SYMCLI), but it will notcollect statistics or initiate any swaps until it is enabled. To change any Optimizer parameters, Optimizermust be stopped using the symoptmz disable command. The parameters are then set using acommand file and the preview , prepare , and commit options. For example, to commit the changesspecified in the command file opt_config.txt , issue the command:

symoptmz file opt_config.txt commit

The preview argument checks that the command file has correct syntax. The prepare argument alsochecks syntax and, in addition, performs some range checks. The commit argument carries out the samesyntax and range checks, and then updates the Optimizer with the modified parameters. It is recommendthat a preview be run on your command files, and then any syntax errors corrected. A prepare shouldthen be run and any out-of-range figures should be corrected. Finally, a commit should be done. Thecommit command will first do a preview and prepare before committing the settings in the command file.

General Optimizer parameters are set using the following commands and syntax in the control file:

set control_parms [start_mode=,]

[min_perf_period=< min_perf >,]

[workload_period=< workload >,][swap_mode=,]

[max_simult_swaps=< max_simult >,]

[swap_rate=< max_swaps >];

The following table describes each parameter.



34/37

Table 1. Parameters in the control file

Parameter Description

start_mode Determines whether Optimizer is enabled or disabled whenever Optimizer is launched, such asafter the service processor is rebooted.

swap_mode Controls whether Optimizer should automatically swap volumes as soon as it finds swaps that

would improve performance. If Optimizer is enabled in AUTO swap mode, each day it willmake up to the number of swaps specified by the swap_rate parameter, under control of theswap time window settings. If Optimizer is enabled in USER_OK swap mode, it will generatelists of swap suggestions approximately once an hour, and then wait for the user to approve theswap list before proceeding.

max_simult_swaps Controls how many swaps Optimizer can perform simultaneously (up to four). The actual valueshould reflect the number of volumes that will be swapped simultaneously. The acceptablevalues are from two (a single pair swapped) to eight (four pairs swapped) Optimizer swaps.

swap_rate Sets the maximum number of swaps that Optimizer is allowed to make in a single day. This parameter is only relevant if swap_mode is set to AUTO. Note that reflects the total number ofvolumes to be swapped in a day. A value of 24 would allow 12 pairs of volumes to be swappedin a day.

min_perf_period Specifies the amount of samples required initially before a recommendation will be made. Youshould make sure that the values you specify are long enough (usually a week) for Optimizer toestablish a good characterization of your typical workloads. This parameter is expressed inhours. Keep in mind that the Optimizer statistics database holds about 14 days worth of data.

workload_period Specifies how far back in time Optimizer should consider when the optimization algorithm isrun. Be careful not to make this value too large or you may include data that is so old it is nolonger representative of your current workloads. This parameter is expressed in hours.

The following control file sets up Optimizer to analyze data from the previous seven days and to startfiguring out swap suggestions after three days of collecting data. It also sets Optimizer to User Approvedmode and sets the maximum number of simultaneous swaps to eight (four pairs of hypervolumes).

set control_parms start_mode=AUTO, min_perf_period=72,

workload_period=168,

swap_mode=USER_OK,

max_simult_swaps=8,

swap_rate=50;

Set t ing User App roved m odeUser Approved mode allows you to see what swaps will occur before they take place. To switch Optimizer

into User Approved mode, use the set control_parms swap_mode=USER_OK; line in thecommand file. Once this is set, Optimizer recalculates a swap list about once every hour as long as sampleshave been collected for the specified minimum performance period. At any time, the latest swap list can beretrieved using the symoptmz show swap_list command. The swap list can then be approved ordeclined using the following syntax in the command file:

set swap

[begin_at=< time_val >,]



35/37

TIMESTAMP=;

The timestamp specified must be the timestamp returned by the last symoptmz show swap_list command. If the command to approve or decline the swap list returns an error, the swap list is probably outof date and a new one is available from the service processor. The latest swap list should then be retrievedagain with the symoptmz show swap_list command.

Set t ing p er fo rm ance t ime wind ow sTo set the performance time windows, use the symoptmz command with the following syntax in thecommand file:

set time_window id=< tw_id >,

type=,

flag=,

period=,

starting=< date_time >, ending=< date_time >,

[days=< day_list >,start_time=< hh:mm >, end_time=< hh:mm >];

where is in the form of MMDDYYYY:HHMMSS and is any comma-separatedcombination of MON, TUE, WED, THU, FRI, SAT, or SUN. For the case of WEEKLY, must

begin with one of the following: MON_START, TUE_START, WED_START, THU_START,FRI_START, SAT_START, or SUN_START, which identifies the first of a series of consecutive days towhich the time window applies. The next entry identifies the day of the week, which concludes the range ofdays.

The WEEKLY_BY_DAY setting is equivalent to what the GUI calls Weekly and the days of theweek must be specified. The window applies to each day specified and each day has its own window.

The WEEKLY setting is equivalent to what the GUI calls Ranging. The starting parameter identifiesthe first of a series of consecutive days that the recurring time period applies to, and the next day in thelist serves as the ending day of the week to which the time period applies.

Using the set time_window command in the command file erases any previously set time windows(both swap and performance), so this command should be used with caution.

To list the performance time windows that have been set up, use the symoptmz show composite command. The symoptmz show parms command will also list any time windows that have been set.

Setting swap priorityUse the following command to set the volume priority:

symoptmz set swap_priority [-range

[Startdevname

]:[Enddevname

]][-nNumDevs

]Use the following command to list the priority settings for all the volumes or a range of volumes:

symoptmz list [-range [ Startdevname ]:[ Enddevname ]][-n NumDevs ]

Optimizer logs and swap historyTo get a list of all swaps that have been completed, use the following command:

symoptmz show swap_hist



36/37

To retrieve the Optimizer activity log, including swaps that have been completed, use the followingcommand:

symoptmz read log_type RUNTIME [ -start ] [ stop ]

To retrieve the Optimizer error log, use the command:

symoptmz read log_type ERROR [ -start ] [ stop ]

The log that is returned includes DOS line-feed characters that can be removed using sed or another texteditor:

cat opt_log.txt | sed s/^M$// > cleaned_opt_log.txt

In a UNIX shell, the ^M should be typed using CTRL-V CTRL-M .

The symoptmz read command can be used to identify why a swap was not performed.

VLUN migrationThe symotmz CLI command can define and start a migration session, The source devices can be eitherenumerated or identified by using an existing Solutions Enabler device group. The list of target disks can

be either enumerated or identified by using the existing SymmWin disk groups. SymmWin disk groupsusually define disk tiers and consist disks from the same type and speed.

For initiating a migration:

migrate

dev[s] [:]

[,[:],...]

TO disk[s] {disk1} [,{disk2},...]

[unmapped=TRUE] [unmasked=TRUE]

[begin_at=];

migrate

device_group

TO disk_group_num


[begin_at=];

migrate

device_group

TO disk[s] {disk1} [,{disk2},...]


[begin_at=];



37/37

migrate

dev[s] [:]

[,[:],...]

TO disk_group_num


[begin_at=];

{diskN} is of the form {DDD,I,T} where

DDD is the director Identifier,

I is the Director Interface, and

T is the Target ID

time_val is in the form of MMDDYYYY:HHMMSS.

Appendix C: TroubleshootingThe Symmetrix Optimizer is a client/server application where the server runs on the service processor andthe clients can run from either the SMC or EMC ControlCenter Console or CLI. Solutions Enabler providesthe infrastructure of communication between the different modules, and EMC ControlCenter provides theinfrastructure for the SymmAgent, server, and Console commands protocol.

Each component in the system has its own log (trace) file ( console.trc , server.trc , egs.log ,sapi-date.log , and optdbg.log ). When troubleshooting a problem, it is critical to first identifywhether the problem is on the server or the client side. This can be done by viewing the individual logs.

Common problems:

Communication with the service processor . Often, when the service processor is busy (or during aconfiguration change session), the Optimizer server is not accessible to client applications. A 1591error indicates a time-out trying to connect to the service processor. Solution: Retry when gettingthis message.

Optimizer is not swapping . By default, swap time windows are defined as exclusion. Solution: Setthe swap times windows to allow swaps.Check if Optimizer is running.Check if the initial and workload analysis periods are set correctly. (Usually a few days for initial timeand one week for the workload period.)If Optimizer was stopped for a few days and then restarted, it might take a while before it startsswapping again. (Optimizer seeks for more than 50 percent coverage of performance data; refer to

Workload and Initial Analysis Period on page 21 for more detail.) Apply button in ControlCenter is not active . Optimizer can accept changes only when it is stopped.

Solution: Stop the Optimizer before committing any change.

emc symmetrix performance using optimizer

Documents