EMC Symmetrix Performance Using Optimizer

EMC Symmetrix Optimizer
A Detailed Review

Abstract
This white paper presents the EMC
Symmetrix
Optimizer product and methodology. Symmetrix Optimizer is

an automated engine that runs on the Symmetrix system. It measures, plans, and executes long-term load
balancing on the back end (physical disks) of the Symmetrix array. In many situations, Symmetrix Optimizer
can improve response time and throughput performance by 20 percent or more. This white paper focuses on
concepts of back-end optimization, the Optimizer analysis process, control parameters, and various
configuration requirements.

May 2008

Copyright 2003, 2008 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 C1062.1
A Detailed Review 2

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
A Detailed Review 3

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 versions
prior 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

A Detailed Review 4

Executive summary
Enterprises of all sizes require consistent and predictable access to mission-critical information as the
fundamental criteria to achieving business success and competitive edge this means the information
infrastructure 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 a
family of information management software solutions offered by EMC to achieve performance tuning at
the disk device level
Introduction
This white paper is intended to provide the reader with an in-depth understanding and an under the
covers 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
Audience
This 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 and
migrating 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 end
users, hosts, and applications in the environment. Migration is performed with constant data availability
and 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 totally
autonomously on the Symmetrix service processor to perform the following steps:
A Detailed Review 5

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 Optimizer
algorithm identifies busy and idle devices and their locations on the physical drives. The algorithm
tries 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 actuator
speed.
3. Once a solution for load balancing has been developed, the next phase is to carry out the Symmetrix
device 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 automated
fashion, 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.
Demo mode
The 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 they
actually purchase the product. In demo mode, Optimizer fills up a sample database and generates a list of
swaps that would lead to improved back-end Symmetrix performance. It then produces graphical output
comparing the current performance with the predicted performance if the suggested swap were to be
executed.
Even though this mode isnt considered an official feature of Symmetrix Optimizer, it is a useful evaluation
tool for potential customers of Symmetrix Optimizer.
Demo mode is available through the service processor and, by default, is enabled. There is no customer
interface to enable demo mode or retrieve its outputthese are both service-processor-resident capabilities
and, as a result, require a CE. Because of this, demo mode should not be used once Optimizer has been
purchased and implemented. If a customer has purchased Optimizer but does not want to allow it to
make swaps, the user approval mode should be used instead of demo mode.
Supported environments
Symmetrix Optimizer consists of two major components:
The Optimizer processing engine runs continuously on the Symmetrix service processor and collects
the statistics, performs the analysis, executes, and monitors the configuration changes. This
component is associated with the version of Symmetrix Enginuity software running on the
Symmetrix array. Versions of the Optimizer engine (with different functionality) are referred to as
different revs of Optimizer (Rev5 5x71, Rev6 5772 and Rev7 5773).
The client user controls for Optimizer parameters. This client can be the EMC SMC, EMC
ControlCenter
GUI, or SYMCLI command line interface.

Optimizer is available for Symmetrix arrays running Enginuity software versions 5x66 and later. Refer to
the EMC Support Matrix (found on the Powerlink
website) for details on minimum versions of Enginuity

software release levels required, along with the compatible user control interfaces for each revision of
Optimizer and the required service processor versions.

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

A Detailed Review 6

Symmetrix Optimizer can optimize all open system and mainframe RAID 1 (mirrored), RAID 5 (3+1 and
7+1), RAID 6 (6+2 and 14+2), and RDF-protected volumes in an array. Optimizer does not work with
volumes configured for use with the AS/400 operating system. Optimizer does not consider business
continuance volumes (BCVs), dynamic reallocation volumes (DRVs), SFS devices, target of SNAP
devices, thin devices, and thin data pools for swapping (refer to the Legality of swaps section on page 12
for a more complete list).
Configuration requirements
In order for Symmetrix Optimizer to function, DRVs must first be configured and Symmetrix Optimizer
enabled by EMC from the service processor. It is important to understand Optimizers requirement of an
open mirror position.
Dynamic Reallocation Volumes (DRV technology)
The DRV is a non-user-addressable logical volume used by Symmetrix Optimizer to temporarily hold
customer 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 system
DRVs must be configured. If more than one simultaneous swap is desired, then additional DRVs are
needed (two for each swap). If there are volumes of mixed size or emulation within the same Symmetrix
frame, 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 TimeFinder
With 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 of
Enginuity, there was a potential for either Optimizer or TimeFinder to fail in its intended task if both
attempted to operate on the same volume at the same time. For specifics on this interaction in Enginuity 66
and 67 and how to avoid the potential conflict, refer to Appendix A: Symmetrix Optimizer and
TimeFinder in Enginuity versions prior to 5568 on page 32.
Requirement for open mirror position
Optimizer does have a requirement for an open mirror position to be able to perform a swap. This limitation
is the four mirror slots for a volume on the Symmetrix system. So, for example, if a RAID 1 device already
has two BCVs established (that is, mmBB), then if Optimizer wants to swap this device it cannot get a
mirror slot for the DRV. If Optimizer does not have a mirror slot available, then it will drop the swap and
rerun the analysis. If Optimizer is in Rollback, Manual, or User-Approved mode, then Optimizer will retry
a number of times and eventually stop an error if a mirror slot does not become available.
Requirement for open configuration lock
In order for Optimizer to perform a swap or a migration, it needs to hold the configuration lock. The
configuration 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. If
another 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 the
configuration lock for the duration of the swap, so other applications will not have the ability to perform
configuration changes during this time.
A Detailed Review 7

How does Symmetrix Optimizer work?
The analysis methodology and the swap procedure are the core technology and the two main components
of the Symmetrix Optimizer solution. The following sections provide a brief description of them.
Analysis
When Symmetrix Optimizer evaluates performance statistics, it evaluates potential volume swaps based on
how 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 when
determining 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 physical
disks, 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 disk
will decrease the seek distance for I/Os to these volumes. When Optimizer swaps volumes, it will try
to 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 because
volumes located on the outer zones of the disk have faster transfer speeds.

Symmetrix Optimizers algorithm uses detailed disk performance information that takes into account
several 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 to
lower the peak service times rather than the average service times.
Performance metrics
Optimizer only looks at back-end activity; it uses the back-end logical volume statistics obtained through a
unique 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 hence
are more efficient. Optimizer does not try to follow DMSP policies; instead, it assumes that reads are
equally spread among all the device mirrors, and all mirrors do all writes.

A Detailed Review 8

Modeling service time
Service time is defined as the sum of seeks, latency, and transfer time.
Seek time Seek time is the time it takes the disk arm to move and position the disk head on the
correct track (that is, move from track X (serving the previous I/O) to track Y (serving the next I/O)).
Optimizer uses a gig-to-gig database to model seek time for different addresses and different disk
drives.
Latency time Latency time is the delay for disk rotation. The latency time is a function of the disk
rotational speed. Optimizer assumes one-third of a spin for each I/O assuming the internal disk
optimization is on.
Transfer time Transfer time is the time that it takes the disk to transfer the data from/to the disk.
Transfer time is a function of the data transfer rate, disk bandwidth, and data layout. Optimizer uses the
Zone Bit Recording (ZBR) database to model the transfer time of data. The ZBR database includes
information about the bandwidth of each zone of the disk.

Accurate seek and latency times are impractical to get because they require a complete trace of the I/O
sequence, so the Optimizer uses a mathematical model to calculate these metrics. The Optimizer model
makes the following assumptions in order to bridge the gap of missing data:
Random Distribution Optimizer assumes that the arrival rate and sequence of I/Os at the back end
are randomly distributed.
Independent I/Os Optimizer does not assume any relationships between two consecutive I/Os.
These two assumptions lead to the following result: Let n be the number of hypers on a disk, let be the
activity done by hyper i at time T, and let SA be the total activity done by the disk at that time.
The probability of serving the next I/O from hyper i is then: regardless of what
the previous and next I/Os are. Based on vendor specification, lets assume that is the time it takes to
seek from hyper i to hyper j, then we can model the seek time (ST) based on Wongs formula:

This result is, in a sense, a worst-case scenario. Optimizer calculated seek time is usually higher than the
actual disk seek time because real-life workloads usually include sequences of I/Os and high percentage of
locality of references.
Finding the best swap
The Optimizer analysis consists of three high-level phases:
Calculate service time: Model and sum the total service time of each disk and for every timestamp
that was marked to be included by the analysis.
Sort disks by activity: Sort all disks by their modeled total service time.
Find best swap: Starting at the busiest disk, check all potential swaps. The analysis process models
what-if scenarios using virtual swaps to estimate the impact of a swap on the service time of the
affected disks. The philosophy of Optimizer is to check as many swaps as possible in order to
guarantee that one of the best swaps is indeed selected.

The biggest challenge is to define how good a swap is and if it is good enough to be a candidate for
execution. A few years ago, when disks were divided into two or four hypers, each swap had the potential
to improve performance by 10, 20, or even 50 percent. This, however, is not the case anymore. Currently,
A Detailed Review 9

EMC allows more than 128 hypers per disk; finding a swap that improves service time by 10 percent or
more on these systems is very rare.
Since using a percentage of improvement as swap goodness criteria is not applicable anymore, Optimizer
had 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 is
assigned 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, Optimizer
checks how close the new-modeled service time is to the disks M0; the closer to M0, the better the swap
is. Usually, two RAID groups are affected by a single swap; the busier disks service time is expected to go
down while the other disks service time is expected to go up. In addition to the M0, the Optimizer also
ensures that the new maximum of service times is less than the old one.
Swap procedure
The 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 case
of three mirror devices or RAID 6 devices the swap procedure does not require a DRV.
Mirrored device swap steps
Hypervolumes are swapped using a four-step process. In order to swap two hypervolumes, the
hypervolumes must be the same size, the same emulation, and, based on the architecture, on the same
system bus or in the same power zone in the Symmetrix DMX architecture in versions prior to 5772. At
least two DRVs must be configured per swap. With Symmetrix Optimizer 5.1.1, up to eight simultaneous
swaps can happen at one time, however, the recommended number of simultaneous swaps is four.

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

Figure 2. Identify volumes to swap

Step 2: Copy a volume to DRV
Symmetrix Optimizer swap commands are passed to SymmWin, which will assign one DRV (DRV
1
) as a
third mirror for hypervolume A. A second DRV (DRV
2
) will be assigned as a third mirror for
hypervolume B. All tracks on the third mirror are marked invalid. Tracks are copied from the valid mirrors
to 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 still
have two (or more) physical mirrors. Host activity to the hypervolumes is now directed to DRVs and the
other mirror.
A Detailed Review 10

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

Figure 4. Copy DRVs to new locations

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

Figure 5. DRVs are split
Note: Swap of three mirror devices does not require a DRV.
RAID 5 swap steps
RAID 5 device swaps require a DRV. The DRV should be of the same size of the DATA portion of the
RAID 5 device and should follow the same configuration rules as DRVs that are used to swap mirrored
devices.

This is the same as for mirrored devices.

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


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

Step 4: DRVs are split

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


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

Legality of swaps
As a rule, Optimizer will never suggest a swap that conflicts with configuration rules as defined by the
microcode, SymmWin, or the configuration groups. For the Symmetrix 3000, 4000, and 8000 hardware
families, all configuration rules are static. However, for the Symmetrix DMX and RMS families, some
configuration rules are static and some are more dynamic and defined in relative manner where an
Optimizer 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).

Dual-Initiator Two mirrors of the same RAID 1 device should never reside on the same DA and
dual-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 can
improve or maintain protection, but never decrease the level of protection. However, some restrictions
should always be followed.
Swappable devices
RAID 5
Parity RAID (parity and data)
BCV, DRV
SFS
WORM
AS400, ICOS, ICL
Saved and virtual snap devices
Targets of snap sessions
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 can
improve or maintain protection, but never decrease the level of protection. However, some restrictions
should always be followed.
Swappable devices
RAID 5
RAID 6 (72+)

BCV, DRV
SFS
WORM
AS400, ICOS, ICL
Saved and virtual snap devices
Targets of snap sessions
Thin provision data pools
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.
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) (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).
Impact of the swap procedure
Each swap performed by Optimizer is the equivalent of two TimeFinder operations. In order to minimize
the effect of the swap procedure on the overall Symmetrix performance, the Symmetrix Optimizer will not
include the same spindle twice in one swap group. In addition, the customer, using QOS controls, can set
lower BCV priority for the STDs to be swapped, and can also plan the swap activities, using the Time
Window feature, to occur on idle business time.
Symmetrix Optimizer features and best practices
Virtual LUN (LUN migration)
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 same
RAID 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 a
single Symmetrix array.
The white paper EMC Symmetrix Optimizer Virtual LUN Technology A Detailed Review describes the
concepts and user interface of the VLUN migration feature, and in this document we will highlight a few
technical subjects relevant to the new functionality.

Regardless of whether the migration is done to empty space on the disk or by swapping unmapped and/or
unmasked devices the input is always one or more devices (the source - the devices to be migrated) and a
list of disks (the target the target locations will be selected from these disks) , the Optimizer role is to
match the sources to the targets based on the configuration rules and user input and then to execute the
migration plan.
Matching the sources to the target list has to follow and obey to all back-end configuration rules and
especially to the new affinity rules that are mandatory since 5772. The affinity rule requires that all
members of a RAID 5, RAID 6, or RAID 1 device reside on the same RAID group; these are groups of 16
(RAID 6 14+2), 8 (RAID 5 7+1 and RAID 6 6+2), 4 (RAID 5 3+1), or 2 (RAID 1) disks of the same disk
class (same type and speed). In order for the migration to pass the validation, the customer has to provide at
least one complete affinity group as target disks, and providing a partial affinity group as input will result in
immediate validation failure, "Can not place all source devices on the specified target disks. Please check
optimizer log for details." The Optimizer log will suggest adding specific disks to the targets.

The swap and migration procedures have to temporary break affinity groups; this is by design, however
once these procedures run to completion all broken affinity rules are resolved. It is important to allow these
procedures to run to end, if for any reason they were stopped in the middle or failed for any other reason, it
is crucial to resume the failed procedure and let it run to completion. Both SymmWin and Optimizer will
not tolerate broken affinity rules after a configuration change is done.

The VLUN migration allows users to migrate metadevices into a different disk tier (for example, from the
performance tier to the capacity tier). A new back-end rule forces all metamembers to reside on the same
disk tier to guarantee consistent performance across all metamembers. While the migration is in progress,
members of metadevices have to reside on different disk classes; this is again by design and both
SymmWin and Optimizer tolerate this scenario, however after the meta migration plan is done meta
consistency rules are applied and re-enforced. Meta migration is not an atomic operation and can take a
while to complete because a metadevice can be large and the Optimizer can migrate only a limited number
of devices (metamembers) in parallel; using the Optimizer migration rule to migrate a complete metadevice
is the preferred way to ensure that all members are migrated and that the configuration changes follow the
business cycles, (the Optimizer Swap Time Windows).

Migration to unmapped/unmasked devices is a bit different from the migration to unused space. In this
mode the Optimizer matched unmapped (or unmasked) devices to the source devices (when the source
device is a metadevice then the Optimizer first tried to find a matching metadevice with the same size and
number of members). This is done to ensure that affinity groups and metarules are enforced and that the
unmapped devices will be ready for future usage upon user request. If the Optimizer cannot match the same
size meta then it will try to find smaller metadevices that fit into the source device or even regular devices
that follow all metadevice back-end restrictions.

Other features include:

Performance awareness - When migrating data into unmapped (or unmasked) devices, the Optimizer
considers the performance of the source devices and of the target disks. The Optimizer will then pick the
best targets based on the configuration rules and the performance.

DRV requirement The underlying technologies of swap and migration are almost identical. The
Optimizer uses DRV devices to hold a temporary copy of the data while the procedure is running. The
same DRV rules and requirements for swaps are applicable for the migration process.

Rollback Each rollback session can undo only one type of configuration change (either swap or
migration). In some cases when the user had sessions of swaps followed by session of migrations, more
than one rollback session is required to undo all changes. (First undo the migration, then undo the swaps,
and so on.)


Configuration change priorities The Optimizer can do migrations that were defined as rules, swaps that
are found by the Optimizer analysis engine in automatic mode, and manual swaps and migrations. The new
Optimizer has a priority mechanism to determine which configuration change to invoke when an inclusion
swap time window becomes active. Based on this logic, rules of meta migrations get the highest priority
once they started; this is in order to accelerate the migration and minimize the time that the metadevice
rules are broken (all members on same speed disks). When there is no meta migration in progress then the
scheduler will use the rules priorities while the automatic swap suggestions are considered as normal
priority,
Swap modes
By default, Optimizer runs in Automatic mode, meaning that when Optimizer determines a swap list, it will
schedule the swap to occur at the next available swap time window. (Refer to the section Swap and
Performance Time Windows on page 24.) However, the user may choose to monitor the swaps before they
start by selecting User Approved mode. In User Approved mode, the Optimizer displays the swap list and
allows 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 define
swaps, migrations) and Rollback (allows the user to undo all swaps done from a specific date and time).
Automatic/User Approved
Switching 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

User-defined swaps
The swap wizard provides an option to define, verify, and schedule user-defined swaps. This feature
allows 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 swaps
that do not have a negative impact on the overall performance of the Symmetrix back end. The
Optimizer uses the same swap legality checks when verifying user-defined swaps as it does in other
swap modes.

Users can either create the list of swaps from scratch or use the Optimizer suggested swap list as the base
line.
Creating a list of swaps from scratch
To 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.

Figure 7. Swap Wizard: Create a user-defined swap list
Using the Optimizer suggested swap list
To 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 be
running 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 (to
run at the next available swap time window) or at a specific time and date.
Rollback
Use the Rollback mode from the swap wizard to undo swaps that conflict with your business rules. The
rollback 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 undo
specific swaps.
Tips
Use User Defined mode rather than Rollback to undo specific swaps.
Rollback swaps can be scheduled for execution according to Optimizer policy.

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

Setting Rollback from SMC
Select the Swap Management tab from the Optimizer main window to start the swap wizard. Then, select
Rollback and click Next. View the swap history to determine the exact date and time to roll back to. All
swaps that occurred on the Symmetrix system between the start date and the current time will be reversed
once 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 to
Optimizer 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 and
time 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 of
Optimizers progress through the swap list.
Analysis reports
Select the Analyze button in the Analyze performance and Schedule dialog box to view the collection of
charts and tables that summarize Optimizers analysis of disk performance. The charts and tables are
displayed within the default browser available on your client workstation. The left panel lists the time
windows when the swap is executed, while the right panel offers a tabbed display of the following three
charts: Affected Disks, Top 20 Disks, and All Disks. Figure 10 shows an example of the affected physical
disks.

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

Figure 9. Analyze Performance and Schedule


Figure 10. Analysis
Workload and Initial Analysis Period
The Workload Analysis Period (Figure 11) specifies the amount of workload sampling that Optimizer
should maintain for sample analysis. The minimum is one hour and the maximum is three weeks. The
default is one week.
The Initial Period (Figure 11) specifies the minimum amount of workload sampling that Optimizer should
complete before analyzing the samples for the first time. This parameter exists in a case where you do not
want to wait until the entire workload period has elapsed before Optimizer commences its analysis and
swap activity. The minimum is one hour and the maximum is the workload analysis period, which is the
default.

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 a
longer workload analysis period (say, three weeks) Optimizer will change the data collection interval
to 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 the
expected time samples.)
Setting Workload Analysis Period and Initial Period from SMC
The Parameter tab of the Optimizer dialog box provides both status information and configuration
capabilities 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

Device Attributes
The Device Attributes dialog box allows you to assign priority attributes to specific logical devices. These
attributes assist Optimizer during sample analysis. Defined attributes are:
High Priority Assign this device the highest priority because it contains crucial data. Optimizer
attempts 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
Tip
Do not define too many devices as high priority because that will eliminate optimization options. As a rule
of thumb, the number of high priority devices should not exceed 10 percent of the number of disks.
Setting Device Attributes from SMC
To 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.


Swap and Performance Time Windows
Symmetrix Optimizer utilizes time windows to schedule swaps and to indicate what time samples are to be
used for the analysis process. By default, Optimizer will include all samples in its analysis. Note that the
default swap time window is set to exclude; no swaps will be performed until the swap time window is
changed.
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. By
default, 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 an
inclusion swap time window; however, a swap that has started may continue beyond the specified time
window.
Use the swap time windows to carefully plan swap sessions and to minimize impact on performance of
critical workloads. Although the swap process runs in low priority, it might introduce some overhead on the
Symmetrix back end. Reducing the maximum number of simultaneous swaps and using the quality of
service (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, analysis
data is always available, and there is no need to collect new statistics when a new time window is
defined.
Time windows that span over the day in which daylight savings time is defined may be off by one
hour. The best practice is to define two separate time windowsone for winter and one for summer.

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

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 table
assigns them a priority, with the first row having the highest priority. If multiple time windows have time
ranges that overlap each other, the higher-listed time window overrides 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.
To add a new time window:
1. Select Swap Time Window or Performance Time Window from the pull-down menu on the left side
of 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.


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 Time
Windows dialog box.

Pace and aggressiveness of optimization
The pace and aggressiveness of optimization can be controlled using two parameters:
Maximum number of swaps per day
Maximum number of simultaneous swaps
The maximum number of swaps per day is a way to limit swap activity on the array. This might be used
when Optimizer is in Automatic mode and the user would like to be more conservative with how quickly
Optimizer can make changes in the environment. At the upper limit, swaps are naturally limited by the
amount of time swaps take to complete. For example, if only one swap pair occurs at a time, and the
average time per swap pair is 2 hours, then there will be no more than 24 moves (12 swap pairs) on average
during 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

swaps, and allows more time for Optimizer to take the resulting modified workload into consideration for
the 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 DRV
devices 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.
Tip
Eight 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 SMC
The maximum number of swaps per day and the maximum number of simultaneous swaps can both be set
in the Parameters tab of the Optimizer dialog box in the Swap Settings area. In order to change
Optimizer parameters, Optimizer must first be stopped.
Logs
It is possible to retrieve Optimizers activity or error logs. These logs are useful if you want to view an
Optimizer error or retrieve past or current state information about Optimizer. The log data is kept on the
Symmetrix service processor.
Tips
Optimizer keeps log data in memory, not files. You can use the Export icon in the Log tab of the
Optimizer 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 SMC
The Log tab (Figure 15) of the Optimizer dialog box lets you retrieve current and past state information on
Optimizer activities and errors. To view log information, select either All Activity or Error Log. Specify
the 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.


Figure 15. Optimizer Logs
Click Get Log to display the log in the lower section of the dialog box, or click Stop to terminate the
retrieval process.
Rule-based analysis
The rule-based analysis feature is aimed to fill in the gaps in the knowledge of the environment of
Symmetrix Optimizer. The Symmetrix Optimizer algorithm runs on the service processor and does not
have access to host information such as host striping, database files, data and indices, or applications. This
feature allows SMC and EMC ControlCenter users and third-party software tools and products to provide
the 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 be
either EMC ControlCenter groups or Optimizer groups.
Users can specify a set of rules. The Symmetrix Optimizer analysis process will generate moves satisfying
these rules. The set of rules can be divided into three types: disk rules, device rules and migration rules.
Disk rules
This section discusses the following disk rules:
Disk pool
Disk exclude
Intra disk

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

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 different
levels of service to different departments.

Disk exclude
A 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 and
wants 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 disk
This 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 be
improvement in performance obtained by reducing seek time and transfer time. This rule is useful in
extreme 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 more
devices from the same stripe group residing on the same disk and reducing performance. By performing
only intra-disk moves on the disks with striped volumes, this can be avoided .
Device rules
Volume avoidance Given a device group for volume avoidance, the Symmetrix Optimizer will not
suggest 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 is
accessed quickly. These volumes should not be situated on the same disk by any move. This can be
achieved 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 be
used 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 bottlenecks
when they are finally used.


Setting the Device Group and Disk Group Rules from SMC
To 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 of
the Optimizer dialog box (Figure 16).

Figure 16. Groups & Rules tab
Disk Group rules
After you click the Groups button in the Groups & Rules tab, the Groups dialog box appears. You can use
the dialog box to create new Optimizer groups, edit the name or membership of an existing group, or delete
an existing group.

Figure 17. Create a new Disk Rule
SMC and SYMAPI groups can be added into the displayed tree by dragging SYMAPI groups into the
dialog 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 impact
on the original group attributes.

Figure 18. Define Disk Group Members

Conclusion
The in-depth perspective of this white paper should have provided the reader with sufficient understanding
and the required knowledge to describe the components and technologies involved with Symmetrix
Optimizer. The setup and configurations screens are particularly useful to help guide the reader through the
various configuration scenarios and the required customization based on user needs.
Finally, and most important, the reader should also appreciate how Symmetrix Optimizer provides
significant benefit to customers enterprises by enhancing the predictability of mission-critical information
performance.
Appendix A: Symmetrix Optimizer and TimeFinder in
Enginuity versions prior to 5568
Optimizer and TimeFinder both use the Symmetrix feature of dynamic mirroring. With this feature, a
special volume like the BCV or DRV can become a mirror copy of a Symmetrix volume. In Enginuity
revisions before 5x68xxxxx, there are potential interactions between BCVs and DRVs due to the rules of
dynamic mirroring. With careful setup, TimeFinder and Optimizer can be used successfully with these
code 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 applications
and 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 no
need for mirror protection.
Potential interactions
Scenario 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 performance
improvement 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 the
Optimizer swap window, Optimizer will not be able to correct the performance issue. The Optimizer swap
window 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 this
is the case, there is a high probability the Optimizers swap selection will be affected by this interaction
scenario. The interaction can be eliminated by implementing one of the two solutions listed in the next
section, 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 TimeFinder
action will fail and give a return code error. The script needs to check the return code and one of the
following 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 a
standard. This is a relatively short period. The probability of this interaction scenario is small. But the
consequence 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.

Solution sets
To ensure no interaction between Optimizer and TimeFinder, the customer can take one of the following
steps.
Solution 1: Exclude all the standard volumes that will be involved with TimeFinder so the Optimizer can
not 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 an
optimal 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 the
TimeFinder activity should be set to complete prior to Optimizers swap time zone. Additionally, the
Optimizer swap time zones should be set to complete prior to TimeFinder activity taking place. This
should separate the dual-copy sessions, blocking the possibility of the conflicts. However, it is possible
that an Optimizer swap will be initiated during a swap time zone, but not complete until some time after the
time zone has ended. Therefore, it is important for TimeFinder scripts to gracefully handle TimeFinder
BCV establish and incremental reestablish command failuresdue to Optimizer still being in the process
of swapping volumes (script needs to wait for swap to complete, then attempt the establish). In 5X65, the
scripts also need to handle incremental reestablish command failuresdue to Optimizer having previously
swapped the primary volume (script needs to attempt a full establish).
Appendix B: Using Optimizer from the CLI
To 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 not
collect statistics or initiate any swaps until it is enabled. To change any Optimizer parameters, Optimizer
must be stopped using the symoptmz disable command. The parameters are then set using a
command file and the preview, prepare, and commit options. For example, to commit the changes
specified 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 also
checks syntax and, in addition, performs some range checks. The commit argument carries out the same
syntax and range checks, and then updates the Optimizer with the modified parameters. It is recommend
that a preview be run on your command files, and then any syntax errors corrected. A prepare should
then be run and any out-of-range figures should be corrected. Finally, a commit should be done. The
commit 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=<AUTO | MANUAL>,]
[min_perf_period=<min_perf>,]
[workload_period=<workload>,]
[swap_mode=<AUTO | USER_OK>,]
[max_simult_swaps=<max_simult>,]
[swap_rate=<max_swaps>];
The following table describes each parameter.


Table 1. Parameters in the control file
Parameter Description
start_mode Determines whether Optimizer is enabled or disabled whenever Optimizer is launched, such as
after 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 will
make up to the number of swaps specified by the swap_rate parameter, under control of the
swap time window settings. If Optimizer is enabled in USER_OK swap mode, it will generate
lists of swap suggestions approximately once an hour, and then wait for the user to approve the
swap list before proceeding.
max_simult_swaps Controls how many swaps Optimizer can perform simultaneously (up to four). The actual value
should reflect the number of volumes that will be swapped simultaneously. The acceptable
values 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 of
volumes to be swapped in a day. A value of 24 would allow 12 pairs of volumes to be swapped
in a day.
min_perf_period Specifies the amount of samples required initially before a recommendation will be made. You
should make sure that the values you specify are long enough (usually a week) for Optimizer to
establish a good characterization of your typical workloads. This parameter is expressed in
hours. 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 is
run. Be careful not to make this value too large or you may include data that is so old it is no
longer 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 start
figuring out swap suggestions after three days of collecting data. It also sets Optimizer to User Approved
mode 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;
Setting User Approved mode
User 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 the
command file. Once this is set, Optimizer recalculates a swap list about once every hour as long as samples
have been collected for the specified minimum performance period. At any time, the latest swap list can be
retrieved using the symoptmz show swap_list command. The swap list can then be approved or
declined using the following syntax in the command file:

set swap <APPROVE | DECLINE>
[begin_at=<time_val>,]

TIMESTAMP=<time_val>;
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 out
of date and a new one is available from the service processor. The latest swap list should then be retrieved
again with the symoptmz show swap_list command.
Setting performance time windows
To set the performance time windows, use the symoptmz command with the following syntax in the
command file:

set time_window id=<tw_id>,
type=<SWAP | PERF>,
flag=<INCLUDE | EXCLUDE>,
period=<ONCE | WEEKLY | WEEKLY_BY_DAY>,
starting=<date_time>, ending=<date_time>,
[days=<day_list>,start_time=<hh:mm>, end_time=<hh:mm>];

where <date_time> is in the form of MMDDYYYY:HHMMSS and <day_list> is any comma-separated
combination of MON, TUE, WED, THU, FRI, SAT, or SUN. For the case of WEEKLY, <day_list> 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 to
which the time window applies. The next entry identifies the day of the week, which concludes the range of
days.
The WEEKLY_BY_DAY setting is equivalent to what the GUI calls Weekly and the days of the
week 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 identifies
the first of a series of consecutive days that the recurring time period applies to, and the next day in the
list 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 priority
Use the following command to set the volume priority:
symoptmz set swap_priority <none|normal|high> [-range
[Startdevname]:[Enddevname]][-n NumDevs]
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 history
To get a list of all swaps that have been completed, use the following command:
symoptmz show swap_hist

To retrieve the Optimizer activity log, including swaps that have been completed, use the following
command:
symoptmz read log_type RUNTIME [-start <date_time>] [stop <date_time>]
To retrieve the Optimizer error log, use the command:
symoptmz read log_type ERROR [-start <date_time>] [stop <date_time>]
The log that is returned includes DOS line-feed characters that can be removed using sed or another text
editor:
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 migration
The symotmz CLI command can define and start a migration session, The source devices can be either
enumerated 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 groups
usually define disk tiers and consist disks from the same type and speed.
For initiating a migration:
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>

migrate
device_group <dgname>
TO disk[s] {disk1} [,{disk2},...]


migrate
dev[s] <start_dev1>[:<end_dev1>]
[,<start_dev2>[:<end_dev2>],...]
TO disk_group_num <disk_group_num>

{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: Troubleshooting
The Symmetrix Optimizer is a client/server application where the server runs on the service processor and
the clients can run from either the SMC or EMC ControlCenter Console or CLI. Solutions Enabler provides
the infrastructure of communication between the different modules, and EMC ControlCenter provides the
infrastructure 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 identify
whether 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 a
configuration change session), the Optimizer server is not accessible to client applications. A 1591
error indicates a time-out trying to connect to the service processor. Solution: Retry when getting
this message.
Optimizer is not swapping. By default, swap time windows are defined as exclusion. Solution: Set
the 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 time
and one week for the workload period.)
If Optimizer was stopped for a few days and then restarted, it might take a while before it starts
swapping 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

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

EMC Symmetrix Performance Using Optimizer

Transféré par

Droits d'auteur :

Formats disponibles

EMC Symmetrix Optimizer

Optimizer product and methodology. Symmetrix Optimizer is

technology, which maintains data

GUI, or SYMCLI command line interface.

website) for details on minimum versions of Enginuity

Vous aimerez peut-être aussi