Docu31003 - FAST VP For Symmetrix VMAX Theory and Best Practices For Planning and Performance PDF

FAST VP for EMC Symmetrix VMAX
Theory and Best Practices

for Planning and Performance
Technical Notes
P/N 300-012-014
REV A07
April, 2014
This technical note contains information on these topics:
Executive summary ................................................................................... 2

Introduction ................................................................................................ 2
Fully Automated Storage Tiering ............................................................ 3
FAST VP ...................................................................................................... 7
FAST VP architecture .............................................................................. 14
FAST VP configuration ........................................................................... 17
FAST VP performance data collection .................................................. 24
FAST VP performance data analysis ..................................................... 29
FAST VP data movement ........................................................................ 35
Advanced FAST VP features .................................................................. 42
FAST VP interoperability ........................................................................ 51
Best practice considerations and recommendations ........................... 56
Conclusion ................................................................................................ 89
Appendix A: FAST VP state ................................................................... 90
Appendix B: Feature support ................................................................. 92
Appendix C: Best practices quick reference ......................................... 94
References ................................................................................................. 97
Executive summary
Executive summary
Information infrastructures must continuously adapt to changing
business requirements. EMC Symmetrix Fully Automated Storage
Tiering for Virtual Pools (FAST VP) automates tiered storage strategies,
in Virtual Provisioning environments, by easily moving workloads
between Symmetrix tiers as performance characteristics change over
time. FAST VP performs data movements, improving performance, and
reducing costs, all while maintaining vital service levels.
Introduction
EMC Symmetrix VMAX FAST VP automates the identification of active
or inactive application data for the purposes of reallocating that data
across different performance/capacity tiers within an array. FAST VP
proactively monitors workloads at both the LUN and sub-LUN level to
identify busy data that would benefit from being moved to higherperforming drives. FAST VP also identifies less-busy data that could be
moved to higher-capacity drives, without affecting existing performance.
This promotion/demotion activity is based on policies that associate a
storage group to multiple drive technologies, or RAID protection
schemes, by way of virtual pools, as well as the performance
requirements of the application contained within the storage group. Data
movement executed during this activity is performed non-disruptively,
without affecting business continuity and data availability.
Audience
This technical notes document is intended for anyone who needs to
understand FAST VP theory, best practices, and associated
recommendations to achieve the best performance for FAST VP
configurations. This document specifically targets EMC customers, sales,
and field technical staff who are either running FAST VP or are
considering FAST VP for future implementation.
Implementing FAST VP for EMC Symmetrix VMAX Series Arrays Technical Notes
Fully Automated Storage Tiering

Significant portions of this document assume a base knowledge
regarding the implementation and management of FAST VP. For
information regarding the implementation and management of FAST VP
in Virtual Provisioning environments, refer to the Implementing Fully
Automated Storage Tiering for Virtual Pools (FAST VP) for EMC
Symmetrix VMAX Family Arrays Technical Note, available at EMC
Online Support.

Fully Automated Storage Tiering (FAST) automates the identification
of active and inactive data for the purposes of relocating application data
across different performance/capacity tiers within an array.
The primary benefits of FAST include:
Improving application performance at the same cost, or providing

the same application performance at lower cost. Cost is defined as:
acquisition (both hardware and software), space/energy, and
management expense.
Elimination of manually tiering applications when workload

characteristics change over time.
Automating the process of identifying data that can benefit from

Enterprise Flash Drives (EFDs) or that can be kept on highercapacity, less-expensive SATA drives without impacting
performance.
Optimizing and prioritizing business applications, allowing

customers to dynamically allocate storage resources within a single
array configuration.
Delivering greater flexibility in meeting different price/performance

ratios throughout the lifecycle of the stored information.
The need for FAST

Due to advances in drive technology, and the need for storage
consolidation, the number of drive types supported by Symmetrix arrays
has grown significantly. These drives span a range of storage-service
specializations and cost characteristics that differ greatly.
Several differences exist between the drive types supported by the
Symmetrix VMAX Family arrays. The primary differences are:
Response time
Cost per unit of storage capacity
Cost per unit of storage request processing
At one extreme lie Enterprise Flash Drives (EFDs), which have a very
low response time and the ability to handle very high levels of requests,
but with a high cost per unit of storage capacity.
At the other extreme are rotating drives with a speed of 7,200 RPM or
lower, such as SATA or near-line SAS drives, which have a low cost per
unit of storage capacity, but high response times and high cost per unit
of storage request processing.
Between these two extremes lie rotating drives with speeds between
10,000 and 15,000 RPM, such as Fibre Channel and SAS drives.
Based on the nature of the differences that exist between these four drive
types, the following observations can be made regarding the most
suitable workload type for each drive:
EFDs are more suited for workloads that have a high back-end
random-read storage request density. Such workloads take
advantage of both the low service time provided by the drive, and
the low cost per unit of storage request processing, without requiring
a lot of storage capacity.
SATA and near-line SAS drives are suited towards workloads that
have a low back-end storage request density.
FC and SAS drives are the best drive type for workloads with a backend storage request density that is neither consistently high nor low.
This disparity in suitable workloads presents both an opportunity and a

challenge for storage administrators.
To the degree that it can be arranged for storage workloads to be served
by the best-suited drive technology, the opportunity exists to improve
application performance, reduce hardware acquisition expenses, and

reduce operating expenses (including energy costs and space
consumption).
The challenge, however, lies in how to realize these benefits without
introducing additional administrative overhead and complexity.
FAST automates the identification of data that should reside on a given
drive technology, and to automatically, and non-disruptively, move data
between tiers to optimize storage resource usage accordingly. This also
needs to be done while taking into account optional constraints on tier
capacity usage that may be imposed on specific application storage
groups.
FAST DP and FAST VP

EMC Symmetrix VMAX FAST DP and FAST VP automate the
identification of data volumes for the purposes of relocating application
data across different performance/capacity tiers within an array, or to an
external array using Federated Tiered Storage (FTS).
Note: Federated Tiered Storage is only available for Open Systems
environments. Also, FTS support applies only to FAST VP.
For more information on Federated Tiered Storage, refer to the Design and
Implementation Best Practices for EMC Symmetrix Federated Tiered Storage
(FTS) Technical Note available at http://support.emc.com.
FAST DP operates on disk group provisioning Symmetrix volumes. Data

movements executed between tiers are performed at the full-LUN level.
FAST VP operates on Virtual Provisioning thin devices. As a result, data
movements can be performed at the sub-LUN level. A single thin device
may have extents allocated across multiple thin pools within an array or
on an external array using FTS.
Note: For more information on Virtual Provisioning, refer to the Best
Practices for Fast, Simple Capacity Allocation with EMC Symmetrix Virtual
Provisioning Technical Note available at http://support.emc.com.
Because FAST DP and FAST VP support different device types (diskgroup provisioning and Virtual Provisioning, respectively), they both
can operate simultaneously within a single array. Aside from some

shared configuration parameters, the management and operation of each
can be considered separately.
The main focus of this document is to discuss the implementation and
management of FAST VP in Virtual Provisioning environments.
Note: For more information on FAST, refer to the Implementing Fully
Automated Storage Tiering (FAST) for EMC Symmetrix VMAX Series Arrays
Technical Note available at http://support.emc.com.
FAST managed objects

There are three main elements related to the use of both FAST and FAST
VP on Symmetrix VMAX arrays. These are:
Storage tier: A shared resource with common drive technologies and

RAID protection.
FAST policy: A set of tier usage rules that provide guidelines for
data placement and movement across Symmetrix tiers to achieve
service levels for one or more storage groups.
Storage group: A logical grouping of devices for common

management.
Figure 1 shows the FAST managed objects.
Figure 1. FAST managed objects
FAST VP
Each of the three managed objects can be created and managed by using
either Unisphere for VMAX, Symmetrix Management Console, or the
Solutions Enabler Command Line Interface (SYMCLI).
FAST VP
FAST VP automates the identification of thin device extents for the
purposes of reallocating application data across different performance
tiers within a single array, or to an external array. FAST VP proactively
monitors workloads at the LUN level and sub-LUN level in order to
identify busy data that would benefit from being moved to higherperforming drives. FAST VP also identifies less-busy data that could be
moved to higher-capacity drives, without impacting performance.
For FAST VP to operate, the three storage elements that need to be
configured are: Storage tiers, FAST policies, and storage groups.
Storage tiers
A Symmetrix storage tier is a specified set of resources of the same drive
technology type (EFD, FC, or SATA) and location (internal or external),
combined with a given RAID protection type (RAID 1, RAID 5, RAID 6,
or unprotected), and the same emulation (FBA or CKD).
Note: The Unprotected RAID type may only be applied to an external tier,
residing on an FTS-connected storage array.
There are two types of storage tiers: Disk-group provisioning (DP) and
Virtual Provisioning (VP).
Disk-group provisioning tiers
The storage-tier type used by FAST is called a DP tier. It is defined by
combining one or more physical disk groups of the same technology
type and a RAID protection type.
Note: A FAST DP tier may not be external.
Virtual Provisioning tiers

For FAST VP, the storage tier is called a VP tier. When defined, VP tiers
FAST VP
contain between one and four thin storage pools. Each thin pool in a
single tier must contain data devices of the same RAID protection type
(with the same number of data members), and be configured on the same
drive technology.
VP tier characteristics
For use with FAST VP, a thin storage pool must contain data devices
configured as the same RAID protection on a single-drive technology,
and of the same emulation. In the case of FC, SAS, and SATA drives, the
rotational speed of the drives must also match. However, two or more
thin pools containing data devices configured on rotating drives of
different speeds, but the same emulation, may be combined in a single
VP tier.
Note: For the purposes of FAST VP, all drives with a rotational speed
between 10,000 and 15,000 RPM are categorized as FC. As such, they can be
combined into a single tier. Similarly, all drives with a rotational speed of
7,200 RPM, or lower, are categorized as SATA.
A thin pool may only belong to one VP tier. Overlapping of pools

between tiers is not allowed.
All VP tiers are considered to be static, meaning that thin pools must be
explicitly added to the tier. However, if data devices are added to an
existing pool, the additional capacity is automatically made available
within the VP tier.
A Symmetrix VMAX storage array supports up to 256 Symmetrix tiers.
Each Symmetrix tier name may contain up to 32 alphanumeric
characters, hyphens (-), and underscores (_). Tier names are not case
sensitive.
FAST policies
A FAST policy groups between one and four tiers (up to three internal
tiers and one external tier). The policy assigns an upper-usage limit for
FAST VP
each storage tier, which specifies the maximum amount of capacity of a
storage group associated with the policy that can reside on that
particular tier.
FAST policies may include storage tiers of only one type, disk group
provisioning (DP) or Virtual Provisioning (VP). Similarly, FAST policies
may only include storage tiers of a single emulation type, FBA or CKD.
The first tier added to a policy determines the type of tiers that can
subsequently be added.
For policies that include VP tiers, the upper capacity usage limit for each
storage tier is specified as a percentage of the configured, logical capacity
of the associated storage group.
The usage limit for each tier must be between 1 percent and 100 percent.
When combined, the upper-usage limit for all thin storage tiers in the
policy must total at least 100 percent, but may be greater than 100
percent.
Creating a policy with a total upper-usage limit greater than 100 percent
allows flexibility with the configuration of a storage group. Data may be
moved between tiers without necessarily having to move a
corresponding amount of other data within the same storage group.
Multiple FAST policies may reuse the same tier, allowing different usage
limits to be applied to different storage groups for the same tier.
A Symmetrix VMAX storage array supports up to 256 FAST policies.
Each FAST policy name may be up to 32 alphanumeric characters,
hyphens (-), and underscores (_). Policy names are not case sensitive.
Note: FAST VP only performs promotion/demotion activity between tiers
defined on differing drive technologies. RAID protection and drive rotational
speed are not considered. As a result, a FAST VP policy should not be created
where two or more tiers use the same drive type. For example, a FAST VP
policy should not contain two or more FC tiers.
Storage groups
A storage group is a logical collection of Symmetrix devices that are to be
managed together. Storage group definitions are shared between FAST
and Auto-provisioning Groups. However, a Symmetrix device may only
FAST VP
belong to one storage group that is under FAST control.

Storage groups are associated with a FAST policy, thereby defining the
VP tiers to which data in the storage group can be allocated on.
FAST VP only supports the movement of certain device types. As a
result of this, a storage group created for the purposes of FAST VP may
not contain the following device types:
Diskless
IBM i (520-byte block emulation), ICOS, ICL
Metadevice members
FTS-encapsulated thin devices
SAVE (SAVDEV)
DATA (TDAT)
DRV
SFS
Vault
Note: Support for IBM i D910 emulation (512-byte block) is provided by
means of FBA emulation pools, tiers, and FAST VP policies.
A Symmetrix VMAX storage array supports up to 8,192 storage groups.

Storage groups may contain up to 4,096 devices. Each storage group
name may be up to 64 alphanumeric characters, hyphens (-), and
underscores (_). Storage group names are not case sensitive.
FAST policy association

A policy associates a storage group with up to four tiers, and defines the
maximum percentage of logical storage capacity in the storage group
that can exist in a particular tier.
The same FAST policy may be applied to multiple storage groups.
However, a storage group may only be associated with one policy.
10
FAST VP
FAST VP supports the association of up to 1,000 storage groups with
FAST policies containing thin storage tiers.
It is possible to have both disk-group-provisioning devices and thin
devices in the same storage group. However, the storage group can only
be associated with one policy. If it is required that both device types be
managed by FAST and FAST VP, then separate storage groups need to
be created. These storage groups then need to be associated with policies
of the appropriate type.
A storage group associated with a FAST policy may only contain thin
devices configured for a single emulation (FBA or CKD). No mixing is
allowed. Similarly, the emulation of the thin devices in the storage group
must match the emulation of the FAST policy to which the group is
being associated.
Note: When associating a storage group to a policy containing VP tiers, the
bound thin devices in the group must be bound to at least one of the thin
pools contained within the policys tiers.
A storage group associated with a FAST VP policy may contain unbound
devices. However, those devices may then only be bound to a thin pool
contained within the tiers in the policy.
Priority
When a storage group is associated with a FAST policy, a priority value
must be assigned to the storage group. This priority value can be
between 1 and 3, with 1 being the highest priority. The default is 2.
When multiple storage groups are associated with FAST VP policies, the
priority value is used when the data contained in the storage groups is
competing for the same resources in one of the associated tiers. Storage
groups with a higher priority are given preference when deciding which
data needs to be moved to another tier.
Storage group considerations
The type of policy, DP or VP, associated with a storage group determines
which devices are managed under that policy. For example, if a storage
group is associated with a policy containing VP tiers, then only the thin
devices in that group are managed by that policy.
11
FAST VP
FAST policy configuration

The FAST VP environment can contain multiple thin storage tiers, FAST
policies, and storage groups.
Figure 2 shows three storage groups. Each storage group is associated
with a policy. These policies associate the storage groups with up to
three storage tiers that are defined in the array.
Figure 2. FAST policy association
12
FAST VP
Based on the System_Optimization policy, FAST VP can place up to 100
percent of the configured, logical capacity of the VP_ProdApp1 storage
group in any of the three associated tiers: RAID 5 (3+1) configured on
EFD, RAID 1 on FC, or RAID 6 (6+2) on SATA. Such a policy gives the
greatest flexibility, as at any given time, all the data can be located on the
most appropriate tier.
Note: The default for any newly created policy is to allow 100 percent of the
storage groups capacity to be placed on any of the included tiers.
In the case of the Custom policy, 10 percent of the configured capacity of

the VP_ProdApp2 storage group can be placed in the EFD tier, 50
percent on the FC tier, and up to 100 percent on both the SATA tier and
external FTS tier.
The No_EFD policy will not move any data to EFD, but does allow 100
percent of the VP_Development storage groups capacity to be on the
SATA or FTS tier, and up to 50 percent on the FC tier.
If the total for all the tiers combined equals 100 percent and if the thin
devices in the storage group are fully allocated, then each tier is utilized
as set in the policy. For example, if a policy was set up as 10 percent EFD,
20 percent FC, and 70 percent SATA, then 10 percent of the storage
groups capacity will always be located on the EFD tier, and so on for the
remaining tiers.
FAST policy compliance

A storage group is considered to be compliant with its associated FAST
policy when all data in the storage group is allocated within the bounds
of the upper-usage limits for each tier contained with the policy.
If all of the data in the storage group is allocated within the tiers
contained within the FAST policy, but the allocated capacity in one tier
exceeds the upper-usage limit for that tier, then the storage group is
considered to be noncompliant. In such a case, the FAST controller
attempts to correct this noncompliance by relocating data from the VP
tier where the usage limit is exceeded to one, or both, of the other tiers
contained in the policy. The desired result is to bring the storage group
into compliance.
13
FAST VP architecture
A special case of noncompliance is when some of the data in the storage

group is allocated in thin pools not contained within any of the VP tiers
within the FAST policy. In this case, the storage group is considered to
be noncompliant, and the data considered to be out-of-policy. Again, the
FAST controller attempts to correct this situation by relocating the outof-policy data to one, two, or all three of the tiers contained in the policy.
There are two components of FAST VP: Symmetrix Enginuity and the
FAST controller.
Symmetrix Enginuity is the storage operating environment that controls
components within the array. The FAST controller is a service that runs
on the service processor.
14
Figure 3. FAST VP components

When FAST VP is active, both components participate in the execution of
two algorithms (the intelligent-tiering algorithm and the allocationcompliance algorithm) to determine appropriate data placement.
The intelligent-tiering algorithm uses performance data collected by
Enginuity, as well as supporting calculations performed by the FAST
controller, to issue data-movement requests to the VLUN VP datamovement engine.
The allocation-compliance algorithm enforces the upper limits of storage
capacity that can be used in each tier by a given storage group by also
issuing data-movement requests to the VLUN VP data-movement
engine.
Performance time windows can be defined to specify when the FAST VP
15
controller should collect performance data. Analysis is then performed to

determine the appropriate tier for devices. By default, performance data
collection occurs 24 hours a day.
Data-movement windows are used to determine when to execute the
data movements necessary to move data between tiers.
Data movements performed by Enginuity are achieved by moving
allocated extents between tiers. The size of data movement can be as
small as 12 tracks, representing a single allocated thin device extent.
More typically, movements are a unit known as an extent group (10 thin
device extents), which is 120 tracks in size.
Note: FAST VP data movement on page 35 provides more information on
the actual data movement.
FAST VP has two modes of operation, Automatic or Off. When operating

in the Automatic mode, data analysis and data movements occur
continuously during the defined data movement windows. In the Off
mode, performance statistics continue to be collected, but no data
analysis or data movements take place.
FAST VP state
There are five reported states for FAST VP. These are:
16
Enabled: All FAST VP functions are performed (performance data

collection, performance data analysis, data-movement request
generation, and data-movement execution).
Disabled: Only performance data collection is performed. Data

analysis is not performed and data movements are not executed.
Disabling: The FAST controller is transitioning from Enabled to

Disabled.
DisabledwithError: The FAST controller has stopped operation due

to an internal error. Statistics collection and FAST VP performance
data movements continue to be performed, however, FAST VP
compliance movements are not performed.
FAST VP configuration
Degraded: FAST VP can perform some or all of its functions.

However, it cannot perform each function fully.
Note: Appendix A: FAST VP state on page 90 provides more information on
each of the FAST controller states.
FAST VP has multiple configuration parameters that control its behavior.
These include time windows that can control when performance data is
collected, included in analysis, and when data movements take place.
Other settings determine the relevance of historical performance data
when analyzed, what percentage of space to reserve in each pool for
activities not associated with FAST VP, and an aggressiveness factor in
generating and executing data-movement requests.
FAST VP time windows

FAST VP utilizes time windows to define certain behaviors regarding
performance data collection and data movement. There are two possible
window types:
Performance time window
Data movement time window
The performance time windows are used to specify when performance

data should be collected by Enginuity.
The data movement time windows define when to perform the data
relocations necessary to move data between tiers. Separate data
movement windows can be defined for full LUN movement, performed
by FAST and Optimizer, and sub-LUN data movement, performed by
FAST VP.
Both performance time windows and data movement windows may be
defined as inclusion or exclusion windows. An inclusion time window
indicates that the action should be performed during the defined time
window. An exclusion time window indicates that the action should not
be performed during the defined time window.
There are two methods for defining time windows, legacy and enhanced.
The legacy method uses the Symmetrix Optimizer interface for creating
17
and managing time windows. The enhanced method uses a time

window management interface.
On Symmetrix VMAX arrays, both the legacy and enhanced methods are
supported. However, only one method can be used at a time. The legacy
method is the default method, but legacy time windows may be
converted to enhanced time windows.
Note: The conversion from legacy to enhanced is a one-way conversion.
There is no method for converting from enhanced to legacy.
Legacy time window characteristics

Using the legacy method, both inclusive and exclusive time windows
may be defined as periodic or non-periodic. Periodic windows allow a
recurrence pattern to be specified as weekly or weekly-by-day. Nonperiodic windows are defined to occur only once. Multiple time
windows, of both performance and data movement, may be defined.
If multiple legacy time windows of the same type have time ranges that
overlap one another, the most recently added time window supersedes
the others, including the system-default time windows.
All defined time windows apply to all devices configured within the
Symmetrix array.
A Symmetrix VMAX storage array supports up to 128 defined legacy
time windows. Each time window name may be up to 32 alphanumeric
characters, hyphens (-), and underscores (_).
Enhanced time window characteristics
Using the enhanced method, inclusive windows are defined by
specifying the days of the week and the times in each day during which
performance metrics are collected or data is moved. Each time window is
defined with a start and end time, in 30-minute increments, and the days
of the week to apply the window.
18
Exclusive windows are defined as a specific time period during which
performance metrics collection or data movement are prevented. Each
exclusive window contains a start date and time, as well as an end date
and time, and may cover several days. The start and end time must be
specified in 30-minute increments.
Multiple inclusive and exclusive enhanced time windows can be defined.
The exclusive time windows have the highest priority and override any
overlapping inclusive time windows.
Enhanced time windows have no associated time-window name.
The performance time windows are used to identify the business cycle
for the Symmetrix array. They specify date and time ranges when
performance samples should be collected, or not collected, for the
purposes of FAST VP performance analysis. The intent of defining
performance time windows is to indicate to FAST which activity periods
should be considered for optimization.
For example, weekends may be used for special utility operations that
should be excluded from optimization. Excluding weekends from the
performance time window means that the activity from the days prior to
the weekend is the best predictor for operations immediately following
the weekend. If the weekend workload is similar to the rest of the week,
and the performance sensitivity is the same, then using all days of the
week may be appropriate.
For legacy time windows, a default performance time window includes
all performance data samples, 24 hours a day, 7 days a week, 365 days a
year.
Note: For legacy time windows, in order to prevent FAST VP from collecting
performance statistics on a continuous basis, the first user-defined window
should be created to exclude data collection. Inclusive time windows can
then be created on top of this exclusive time window.
For enhanced time windows, the default behavior is also to collect

performance data, 24 hours a day, 7 days a week. When the first
inclusive performance window is created, the default behavior is
overridden, and performance metrics are only collected during the
19
defined window.
Data movement time windows are used to specify date and time ranges
when data movements are allowed, or not allowed. FAST VP data
movements run as low-priority tasks on the Symmetrix back end. They
can introduce additional processing overhead on the back end, however,
host I/O should not be impacted. Data-movement windows can be
planned so they minimize any impact on the performance of other, more
critical workloads.
For legacy time windows, a default data movement time window
prevents any data movement, 24 hours a day, 7 days a week, 365 days a
year.
For enhanced time windows, there is no default data-movement
window. However, until an inclusive window is defined, the default
behavior leads to not allowing any data movement to occur.
FAST VP settings
There are multiple settings that affect the behavior of FAST VP. These
include:
FAST VP Data Movement Mode
Workload Analysis Period
Initial Analysis Period
Pool Reserved Capacity (PRC)
FAST VP Relocation Rate (FRR)
VP Allocation by FAST Policy
FAST VP Time to Compress
FAST VP Compression Rate
The following sections describe each of these settings, their effect on the
behavior of FAST VP, as well as possible values and the default-setting
values.
20
FAST VP Data Movement Mode
FAST VP, when enabled, may operate in one of two modes, Automatic
or Off.
In Automatic mode, a data movement request can be generated to move
data based on performance workload. Also, data-movement requests
based on capacity utilization may be generated. These operations are
performed during the periods allowed by the data-movement windows.
In Off mode, no data-movement requests are generated. As a result, no
data movements occur. However, performance metrics continue to be
collected. The default mode is Off.
The Workload Analysis Period determines the degree to which FAST VP
metrics are influenced by recent host activity, and also less-recent host
activity, that takes place while the performance time window is
considered open.
The longer the time defined in the Workload Analysis Period, the greater
the amount of weight assigned to less-recent host activity.
The Workload Analysis Period can be configured to be between 2 hours
and 4 weeks. The default is 1 week (7 days).
Note: For more information on the effect of the Workload Analysis Period,
refer to FAST VP performance data collection on page 24.

The Initial Analysis Period defines the minimum amount of time a thin
device should be under FAST VP management before any performancerelated data movements should be applied. This period only accounts for
time passed while the performance time window is open.
This value should be set to allow sufficient data samples for FAST VP to
establish a good characterization of the typical workload on that device.
This value allows FAST VP to commence analysis and movement
activities on the device, prior to the full Workload Analysis Period
elapsing (if so desired).
The Initial Analysis Period can be configured to be between 2 hours and
21
4 weeks, however, it cannot exceed the Workload Analysis Period. The

default is 8 hours.
Pool Reserved Capacity
The Pool Reserved Capacity (PRC) reserves a percentage of each pool
included in a VP tier for activities not associated with FAST VP. This
ensures that FAST VP data movements do not fill a thin pool, and
subsequently cause a new extent allocation to fail, as result of a host
write.
When the percentage of unallocated space in a thin pool is equal to the
PRC, FAST VP no longer moves data into that pool. However, data
movements may continue to occur out of the pool to other pools. When
the percentage of unallocated space becomes greater than the PRC, FAST
VP can begin performing data movements into that pool again.
Note: The PRC value is calculated against the enabled capacity of each thin
pool. Any disabled DATA devices in the pool are not considered when
calculating the PRC.
The PRC can be set both system-wide and for each individual pool. By
default, the system-wide setting is applied to all thin pools that have
been included in VP tier definitions. However, this can be overridden for
each individual pool by using the pool-level setting.
The system-wide PRC can be configured to be between 1 percent and 80
percent. The default system-wide PRC is 10 percent.
The pool-level PRC can be configured to be between 1 percent and 80
percent, or set to NONE. If the PRC is set to NONE, then the systemwide setting is used. The default pool-level PRC is NONE.
FAST VP Relocation Rate
The FAST VP Relocation Rate (FRR) is a quality of service (QoS) setting
for FAST VP and affects the aggressiveness of data-movement requests
generated by FAST VP. This aggressiveness is measured as the amount
22
of data that is requested to be moved at any given time, and the priority
given to moving the data between pools.
The FRR can be configured to be between 1 and 10, with 1 being the most
aggressive. The default is 5.
Note: The rate at which data is moved between pools can also be controlled
by the Symmetrix Quality of Service VLUN setting.

The VP Allocation by FAST Policy feature allows new allocations to
come from any of the thin pools included in the FAST VP policy that the
thin device is associated with.
With this feature enabled, FAST VP attempts to allocate new writes in
the most appropriate tier first, based on available performance metrics. If
no performance metrics are available, an attempt is made to allocate to
the pool to which the device is bound.
If the pool initially chosen to allocate the data is full, FAST VP then looks
to other pools contained within the FAST VP policy and allocates from
there. As long as there is space available in at least one pool within the
policy, all new extent allocations will be successful.
The allocation by policy feature is enabled at the Symmetrix array level
and applies to all allocations for all devices managed by FAST VP. The
feature is either Enabled or Disabled. The default setting is Disabled.
When disabled, new allocations only come from the pool to which the
thin device is bound.
Note: For more information on the decision making process of the VP
allocation by FAST policy feature, refer to VP Allocation by FAST Policy on
page 42.

FAST VP Compression automates VP compression at the sub-LUN level
for thin devices that are managed by FAST VP.
The FAST VP Time to Compress parameter enables the use of FAST VP
Compression and sets the inactivity threshold for when data becomes
23
FAST VP performance data collection
eligible for compression.

The time to compress can be configured to be between 40 and 400 days,
as well as never. The default is never, meaning FAST VP will not
automatically compress any data.
When set to a particular number of days, any data managed by FAST VP
that has been inactive for at least that number of days will be considered
Note: For a thin devices data to be compressed by FAST VP, the policy the
device is associated with must also contain a pool that has been compression
enabled.
For more information on automated VP compression, refer to FAST VP
Compression on page 47.

The FAST Compression Rate is a quality of service (QoS) setting for the
automate VP compression performed by FAST VP. It affects the
aggressiveness with which data is compressed, after it has been inactive
beyond the time to compress value.
The compression rate can be configured to be between 1 and 10, with 1
being the most aggressive. The default is 5.

As previously discussed, performance data for use by FAST VP is
collected and maintained by Symmetrix Enginuity. This data is then
analyzed by the FAST controller and guidelines are generated for the
placement of thin device data on the defined VP tiers within the array.
The following sections discuss the collection and decaying of the thin
device performance metrics.
24

Thin device performance collection
Performance metrics collected by FAST VP are measured at both the fullLUN and sub-LUN levels for all thin devices associated with a policy.
At the sub-LUN level, each thin device is broken up into multiple
regions, known as extent groups and extent group sets. Each thin device
is made up of multiple extent group sets which, in turn, contain multiple
extent groups.
Figure 4 shows a graphic representation of a thin device divided into
each of these separate regions.
Figure 4. Thin device performance collection regions

Each extent group is made up of ten contiguous thin device extents. With
each thin device extent being 12 tracks in size, an extent group represents
120 tracks of the device.
Each extent group set is made up of 48 contiguous extent groups,
representing 5,760 tracks of the device.
The metrics collected at each sub-LUN level allow FAST VP to make
separate data-movement requests for each extent group of the device,
120 tracks.
Emulation considerations
FAST VP supports both FBA and CKD emulations. The size of the extent
groups and extent group sets are the same size for both emulations, in
terms of tracks. However, the tracks sizes are different for each of the
25
emulations, 64 KB for FBA and 57 KB for CKD.

The following table shows the relative size of the thin device extent,
extent group, and extent group set for both FBA and CKD.
Element
Tracks
FBA
CKD
Thin device extent
12
768 KB
684 KB
FAST VP extent
group
120
7,680 KB/
7.5 MB
6,840 KB/
6.7 MB
FAST VP extent
group set
5,760
360 MB
320.6 MB
Performance metrics
When collecting performance data at the LUN level and sub-LUN level
for use by FAST VP, Enginuity only collects statistics related to
Symmetrix back-end activity that is the result of host I/O.
The metrics collected are:
Read miss
Write
Prefetch (sequential read)
The read-miss metric accounts for each DA read operation that is

performed. Reads to areas of a thin device that have not had space
allocated in a thin pool are not counted. Also, read hits, which are
serviced from cache, are not considered.
Write operations are counted in terms of the number of distinct DA
operations that are performed. The metric accounts for when a write is
destaged. Write hits, to cache, are not considered.
Writes related to specific RAID protection schemes are not counted. In
the case of RAID 1 protected devices, the write I/O is only counted for
one of the mirrors. In the case of RAID 5 and RAID 6 protected devices,
parity writes are not counted.
26

Prefetch operations are accounted for in terms of the number of distinct
DA operations performed to prefetch data spanning a FAST VP extent.
This metric considers each DA read operation performed as a prefetch
operation.
Workload related to internal copy operations, such as drive rebuilds,
clone operations, VLUN migrations, or even FAST VP data movements,
is not included in the FAST VP metrics.
Note: In the case of local replication sessions where host read I/Os to a target
device are redirected to the source device, the read activity is counted against
the source device. This is typically the case for TimeFinder/Clone,
TimeFinder/Snap, and TimeFinder VP Snap when the session status is
CopyOnWrite. Note: Only performance metrics collected during user-defined
performance time windows are included in FAST VP analysis.
I/O activity rates

For each thin device, a short-term and long-term activity rate is
maintained at the sub-LUN level. Both activity rates are calculated as
weighted moving averages, modeling both recent and less recent
workload on each region of the thin device.
As new performance metrics are collected, the previously stored shortterm and long-term activity rates are decreased by the application of an
exponential decay function. This lessens the influence of previously
collected metrics. The newly collected metrics are then added to the
decayed rates to calculate the new short-term and long-term activity
rates.
The rate of decay applied to the stored I/O rates depends upon the userdefined Workload Analysis Period, with the short-term rate decayed at a
faster rate than then long-term rate.
Note: The decay function is only applied to previously collected metrics
while the user-defined performance time window is open.
As an example, when calculating the long-term activity rate with the

default Workload Analysis Period of 168 hours, an I/O that has just been
received is weighted twice as much as an I/O received 24 hours earlier.
27
Thin device performance score

Based on the performance statistics collected, a prioritized performance
score is generated for the extent groups of each thin device. This score is
calculated by combining two activity rates maintained in Enginuity (the
short-term activity rate and the long-term activity rate) and multiplying
that by a factor determined by the priority assigned to the storage group
when it was associated with the FAST policy.
Then FAST VP places those extent groups with the highest performance
score onto the higher-performing tiers within the associated policy.
Storage group association

The sub-LUN performance metrics previously discussed are collected for
all bound thin devices.
Disassociating a storage group from a FAST policy, or removing devices
from the storage group, causes Enginuity to stop including performance
metrics for those devices in analysis for the purposes of FAST VP.
If the thin device is associated again to a FAST policy, the Initial Analysis
Period must pass for that device before data movements can be
performed once again.
Reassociation
A storage group may be moved from one policy to another, without
interruption to ongoing FAST VP management, by reassociating the
storage group to a new policy.
When a reassociation is performed, all performance metrics previously
collected for the devices in the storage group are maintained within
Enginuity. Also, all attributes of the association, for example priority, are
maintained for the association to the new policy.
28
FAST VP performance data analysis

Cache consumption
To maintain the sub-LUN level metrics collected by Enginuity, the
Symmetrix array allocates one cache slot for each thin device that is
bound.
When managing FBA metadevices, cache slots are allocated for both the
metahead and for each of the metamembers.
Note: Each cache slot on a Symmetrix VMAX Series array is one track in size.

FAST VP uses two distinct algorithms, one performance oriented and
one capacity allocation oriented, in order to determine the appropriate
tier to which a device should belong. These algorithms are:
Intelligent-tiering algorithm
Allocation-compliance algorithm
The intelligent-tiering algorithm considers the performance metrics of all

thin devices under FAST VP control and determines the appropriate tier
for each extent group.
The allocation-compliance algorithm is used to enforce the per-tier
storage capacity usage limits.
The following sections provide additional data on each of the algorithms.
Intelligent-tiering algorithm
The goal of the intelligent-tiering algorithm is to use the performance
metrics collected at the sub-LUN level to determine which tier each
extent group should reside in and to submit the needed data movements
to the Virtual LUN (VLUN) VP data-movement engine.
The determination of which extent groups need to be moved is
performed by a task that runs within the Symmetrix array.
Algorithm structure
The intelligent-tiering algorithm is structured into two components:
A main component that executes within Enginuity
A secondary, supporting, component that executes within the FAST
29
controller on the service processor

The main component assesses whether extent groups need to be moved
to optimize the use of the FAST VP storage tiers. If so, the required datamovement requests are issued to the VLUN VP data-movement engine.
When determining the appropriate tier for each extent group, the main
component makes use of both the FAST VP metrics, previously
discussed, and supporting calculations performed by the secondary
component on the service processor.
Tier ranking
External tiers can be user-defined as a particular technology, which sets a
performance expectation for that tier.
Within a FAST VP policy, tiers are ranked based on the drive technology
of the pools within the each tier (EFD, FC, or SATA) as well as the
location of the tier (internal or external).
For the six possible tier types that can be included in a FAST VP policy,
the rankings are as follows:
Internal EFD
External EFD
Internal FC
External FC
Internal SATA
External SATA
Note: A FAST VP policy may only contain a maximum of four tiers, up to
three internal and one external.
Promotion-and-demotion thresholds
The supporting component of the intelligent-tiering algorithm, running
on the service processor, does not make explicit data-movement
requests. Rather, it produces a set of promotion-and-demotion
30

thresholds that define recommendations for data placement across thin
tiers.
In a multi-tier configuration, depending on the number of tiers included
in a policy, there are several thresholds that can be generated. These
include:
Internal EFD promotion threshold
External EFD promotion threshold
Internal FC promotion threshold
External FC promotion threshold
Internal SATA promotion threshold
External EFD demotion threshold
Internal FC demotion threshold
External FC demotion threshold
Internal SATA demotion threshold
External SATA demotion threshold
However, as a FAST VP policy can only contain a maximum of four tiers,

each extent group is only compared to up to four thresholds.
Note: There is no internal EFD demotion threshold, as data is never demoted
to the internal EFD tier. Similarly, there is no external SATA promotion
threshold, as data is never promoted to external SATA.
These thresholds allow Enginuity to determine and schedule specific

data movements to optimize the allocation of thin devices under FAST
VP control.
The thresholds are calculated using the performance metrics collected
and the capacity available in each tier. As a result, the thresholds are
dynamic and may increase or decrease as the workload on the devices
managed by FAST VP increases or decreases.
When calculating the thresholds, the goal is to maximize the utilization
of the highest performing tier in the FAST VP policy, while also
proactively demoting inactive or lightly accessed data to the most costeffective tier.
Intelligent-tiering data-movement requests
The size of the data-movement requests generated by the intelligentImplementing FAST VP for EMC Symmetrix VMAX Series Arrays Technical Notes
31
tiering algorithm depends foremost on the amount of capacity that it

deems not to be on the appropriate tier. It also depends on the size of the
VMAX array.
Each back-end disk adapter (DA) in the array is responsible for executing
data movements. The more DAs there are available, the more data that
can be moved at a single time, and, therefore, the larger the request size.
The FAST VP relocation rate does not affect the size of the request
generated, but it does influence the pace at which the requests are
executed and data is moved.
Intelligenttiering-algorithm execution
Operating within Enginuity, the main component of the intelligenttiering algorithm runs continuously during open data-movement
windows, when FAST is enabled and the FAST VP operating mode is
Automatic. As a result, performance-related data movements can occur
continuously during an open data-movement window.
The supporting component, operating within the FAST controller on the
service processor, runs every 10 minutes. It recalculates the promotionand-demotion thresholds based on changes in workload on the devices
managed by FAST VP.
Allocation-compliance algorithm
The goal of the allocation-compliance algorithm is to detect and correct
situations where the allocated capacity for a particular storage group
within a thin storage tier exceeds the maximum capacity allowed by the
associated FAST policy.
Policy compliance
A storage group is considered to be in compliance with its associated
FAST policy when the configured capacity of the thin devices in the
storage group is located on tiers defined in the policy, and when the
usage of each tier is within the upper limits of the tier usage limits
specified in the policy.
32

Compliance violations may occur for multiple reasons, including:
New extent allocations performed for thin devices managed by

FAST VP
Changes made to the upper-usage limits for a VP tier in a FAST

policy
Adding thin devices to a storage group that are themselves out of

compliance
Manual VLUN VP migrations of thin devices
Compliance data-movement requests

When a compliance violation exists, the algorithm generates a datamovement request to return the allocations within the required limits.
This request explicitly indicates which thin device extents should be
moved, and the specific thin pools to which they should be moved.
The size of the data-movement request depends on the amount of
capacity that is currently out of compliance, but also on the user-defined
relocation rate. The maximum size of request that can be generated by
the allocation-compliance algorithm is 10 GB worth of data movements.
When the relocation rate is set to anything other than 1, the FAST
controller divides 10 GB by the relocation rate to determine the new
maximum. For example, if the relocation rate is set to 2, the maximum
request size is 5 GB; if it is 10, the maximum size is 1 GB.
Note: The allocation-compliance algorithm is not designed to be a tool for
bulk data movement. To move large amounts of data from one pool to
another, for a given set of devices, VLUN VP should be used. VLUN VP
allows both a source pool and a target pool to be specified to zero in on the
exact data to be migrated.
Intelligent-tiering-algorithm coordination
The compliance algorithm attempts to minimize the amount of
movements performed to correct compliance that may, in turn, generate
movements performed by the intelligent-tiering algorithm.
Compliance violations can be corrected by coordinating the movement
requests with the analysis performed by the intelligent-tiering algorithm
to determine the most appropriate extents to be moved to the most
appropriate tier.
33
Allocation-compliance-algorithm execution
The compliance algorithm runs every 10 minutes during open datamovement windows, when FAST is enabled, and the FAST VP operating
mode is Automatic.
FAST controller availability

Should the FAST controller, a resident on the service processor, become
unavailable, FAST VP will continue operating, albeit in a degraded
mode. During this time, each component of FAST VP is affected in a
different way.
In the case of the intelligent-tiering algorithm, the algorithm is structured
into two components:
The main component, which executes within Enginuity
A supporting component that executes within the FAST controller

(on the SP)
The FAST controller is responsible for performing supporting analysis,

calculating the promotion-and-demotion thresholds. Each time the
thresholds are recalculated and passed to Enginuity, an expiration
timestamp is placed on the thresholds and is set at four hours from
creation. At the same time, a more conservative, backup set of thresholds
is created with an expiration timestamp of four days from creation.
In the case where the FAST controller becomes unavailable and no new
thresholds are generated, Enginuity will use the last good thresholds for
four hours, and then switch to the backup thresholds for four days. After
four days, the performance movements will stop.
Performance data collection is unaffected by a controller outage, as it
takes place completely within Enginuity. The short-term and long-term
activity rates are also unaffected, as they are calculated and stored within
Enginuity. No performance data information is lost.
34
FAST VP data movement

When the FAST controller is restarted, the most recent activity rates are
read from Enginuity, and new thresholds are calculated based on the
most recent workload information.
In the case of the allocation-compliance algorithm, however, when the
FAST controller becomes unavailable, no compliance-based movement
requests are generated. As such, the ability of FAST VP to correct
allocation-compliance violations is impaired. However, performance
movements may correct compliance as it moves data.

There are two types of data movement that can occur under FAST VP:
Intelligent-tiering-algorithm-related movements and allocationcompliance-algorithm-related movements. Both types of data movement
occur only during user-defined data movement windows.
Intelligent-tiering-algorithm-related movements are requested and
executed by Enginuity. These data movements are governed by the
workload on each extent group, but are executed only within the
constraints of the associated FAST policy. This is to say that performance
movements will not cause a storage group to become noncompliant with
its FAST policy.
Allocationcompliance-algorithm-related movements are generated by
the FAST controller, and executed by Enginuity. These movements bring
the capacity of the storage group back within the boundaries specified by
the associated policy. Performance information from the intelligenttiering algorithm is used to determine the more appropriate sub-extents
to move when restoring compliance.
Data-movement engine
Data movements executed by FAST VP are performed by the VLUN VP
data-movement engine. They involve moving thin device extents
between thin pools within the array.
Extents are moved by way of a move process only. Extents are not
swapped between pools.
The movement of extents, or extent groups, does not change the thin
35
device binding information. The thin device remains bound to the pool it
was originally bound to. New allocations for the thin device, as the result
of host writes, continue to come from the bound pool, unless VP
allocation by FAST VP is enabled.
Movement considerations
To complete a move, the following must hold true:
The FAST VP operating mode must be Automatic.
The VP data movement window must be open.
The thin device affected must not be pinned.
There must be sufficient unallocated space in the thin pools included

in the destination tier to accommodate the data being moved.
The destination tier must contain at least one thin pool that has not
exceeded the pool reserved capacity (PRC).
Note: If the selected destination tier contains only pools that have reached the
PRC limit, then an alternative tier may be considered by the movement task.
Other movement considerations include:
Only extents that are allocated are moved.
No back-end configuration changes are performed during a FAST

VP data movement, and, as a result, no configuration locks are held
during the process.
As swaps are not performed, there is no requirement for any swap

space, such as DRVs, to facilitate data movement.
Data-movement process
The following section details the process followed during a FAST VP
data movement.
In the following illustration, device 100 is bound to an FC thin pool. The
device is associated with a FAST policy that also contains tiers with an
EFD pool and a SATA pool.
36

Over time, FAST VP has determined that several of the devices extents
need to be moved to the other tiers within the policy.
As data movements can occur continuously during the thin data
movement time window, a single devices allocations may change
multiple times while it is actively managed by FAST VP.
Initial allocation
Figure 5 shows the thin device with its initial binding and allocation on a
FC tier. The additional tiers the device is associated with as part of the
FAST policy are also shown.
Figure 5. FAST VP data movement: Initial allocation and associated tiers

Extent movements
After the initial analysis period has passed, the performance metrics
collected for device 100 are analyzed by the FAST controller. Based on
this performance analysis, it is determined that several of the allocated
extents need to be moved to the other tiers in the FAST policy.
Due to a higher level of activity, the extents labeled 1 and 6 are promoted
to the EFD tier. Meanwhile, the extents labeled 2, 3, 7, and 8 are demoted
37
to SATA, as they were determined to be less active.

The data movements are queued up on each DA, and the data is
transferred. When the data transfer is complete, the space originally
consumed by the extents in the FC tier is deallocated and is reported as
free space in that tier, as shown in Figure 6.
Figure 6. FAST VP data movement: Extent relocations

Even though data has been moved to other tiers within the array, the
thin device remains bound to the pool it was originally bound to, which
is contained in the FC tier.
New host writes
By default, new allocations that occur as a result of host writes come
from the pool to which the thin device is bound.
38
Note: The default behavior of allocating new extents from the pool to which
the device is bound may be changed. See VP Allocation by FAST Policy on
page 42.
Figure 7 shows additional extents 9 and 10 that have been allocated in

the pool.
Figure 7. FAST VP data movements: New host writes

Continuous operations
Over longer periods of time, new data is generated, causing more
allocations. Also, data access patterns may change, causing additional
promotions and demotions to be performed.
Figure 8 shows a snapshot of device 100 and its data allocation across all
three tiers.
39
Figure 8. FAST VP data movement: Continuous operations
Data movement control

Several mechanisms exist for controlling the movement of data related to
thin devices under FAST VP control.
Device pinning
To prevent FAST VP changing the current tiering allocation of a thin
device, a feature called device pinning may be used. Pinning a device
locks all extent allocations for the device in their current locations, and
prevents FAST VP from relocating them.
Any new allocations performed for a pinned device comes from the thin
pool to which the device is bound. If allocation by policy is enabled, new
allocations for a pinned thin device will be performed as if no
40

performance metrics are available for the device. These allocations are
not moved by FAST VP.
The thin device needs to be unpinned to re-enable data movement.
Note: While a device is pinned, performance statistics continue to be
collected for that device.
FAST policy disassociation

Aside from pinning a device to prevent a thin devices allocation from
being changed by FAST VP, the device may be removed from the storage
group that is associated to a FAST policy. Removing the device from the
storage group disassociates it from the FAST policy and removes the
device from the control of FAST VP. As a result, no further data
movements are performed for that device. Allocated data previously
moved by FAST VP remains in its current locations and is not
automatically returned to the thin devices bound pool.
Note: If the thin device is associated again to a FAST policy, the Initial
Analysis Period must pass for that device before data movements can once
again be performed.
Changing the quality of service

If the performed data movements by FAST VP are impacting other
applications or replication tasks within the Symmetrix array, quality of
service (QoS) tools may be used to change the pace at which data is
moved. Slowing down the FAST VP data movements gives higher
priority to the other tasks running on the Symmetrix back end.
The VLUN copy pace can be set between 0 and 16 inclusively, with 0
being the fastest and 16 being the slowest. The default QoS value is 0.
Setting the pace value to 16 gives the FAST VP data movements the
lowest priority on the array. Once the unrelated copy tasks have
completed, the pace setting can be reset to 0.
41
Advanced FAST VP features
Note: QoS can be used to change the copy pace for individual devices under
FAST VP control. The FAST Relocation Rate can be used to change the copy
pace for all devices under FAST VP control.
Operating mode
To stop data movements for all thin devices under FAST VP control, the
operating mode may be set to Off. While off, performance statistics
continue to be collected by Enginuity. However, no data-movement
requests are generated by Enginuity or the FAST controller.

Along with the features already described, advanced features exist that
further improve the ease of management and usability of FAST VP.
These advanced features include:
VP Allocation by FAST Policy: Allows thin device allocations to

come from thin pools other than the pool to which the devices are
bound.
FAST VP SRDF coordination: Allows promotion-and-demotion

decisions of data belonging to a thin R2 device to account for
workload on the corresponding thin R1 device.
FAST VP Compression: Automates VP compression at the sub-LUN

level for thin devices that are managed by FAST VP.
User-defined FTS tier: Allows an external FTS tier to be specified as

something other than the lowest tier.
The following sections describe each of these advanced features in detail.

By default, new extent allocations generated by writes to a thin device
come from the thin pool to which the device is bound. This behavior has
two potential consequences. First, data allocated from the bound pool
may be promoted or demoted shortly after the allocation that causes an
42

additional movement of data on the back end. Second, should the bound
pool fill up, a write generating a new allocation to the pool may fail.
The VP Allocation by FAST Policy feature addresses these potential
consequences for devices managed by FAST VP. When the feature is
enabled, new allocations can come from any of the thin pools included in
the FAST VP policy to which the thin device is associated. (Allocations
are not limited to just the bound pool.)
The allocation by policy feature is a setting that is either Enabled or
Disabled across the entire Symmetrix array. The default setting is
Disabled. When disabled, new allocations come only from the pool to
which the thin device is bound.
When this feature is enabled, FAST VP attempts, based on available
performance metrics, to direct the allocation to the most appropriate tier.
If the selected pool is full, an alternate pool is chosen from the other thin
pools included within the FAST VP policy.
The following section describes the decision-making criteria for selecting
the thin pool from which to allocate.
Allocation by policy decision criteria
As previously mentioned, FAST VP collects performance metrics at three
distinct levels for a thin device: Full LUN, extent group set, and extent
group. Performance metrics already collected for each extent group set
can be applied to newly allocated data within each of those sets.
When allocation by policy is enabled on a Symmetrix array, FAST VP
first checks for the existence of performance metrics on the extent group
set for which the new allocation is generated.
If available, the performance metrics are used to determine the most
appropriate tier, from a workload perspective, from which to allocate the
extent. Once the tier has been selected, a pool within the tier is selected,
and the allocation is attempted.
If there are no performance metrics available for the extent group set
being written to (this would happen when the entire set is unallocated),
FAST VP attempts to allocate new extents from the pool to which the
device is bound.
In either of these cases, should the selected pool be full, an alternate pool
43
within the policy is chosen.

To determine the alternate pool, the tiers are sorted in ascending order of
the configured capacity of each tier. Each tier is then checked for
available space within each pool in the tier, and the allocation attempted.
Should the selected pool be full, FAST VP moves onto the next pool
within the tier (if it exists), or the next tier on the list.
If a selected tier contains multiple pools, the allocation pool is selected at
random.
This continues until the allocation is successful, or until a determination
is made that all pools within the policy are full. As long as there is space
available in at least one of the pools within the policy, all new extent
allocations will be successful.
Note: If the device generating the allocation is pinned, the existence of
performance metrics is ignored. FAST VP first attempts to allocate from the
bound pool. If the bound pool is full, an alternate pool within the policy is
chosen.
FAST VP SRDF coordination

FAST VP has no restrictions in its ability to manage SRDF devices.
However, it must be considered that FAST VP data movements are
restricted to the array upon which FAST VP is operating. By default,
however, there is no coordination of data movements between the source
and target arrays. FAST VP acts independently on both.
While an R1 device typically undergoes a read-and-write workload mix,
the corresponding R2 device only sees a write workload. (Reads against
the R1 are not propagated across the link.) A consequence of this is that
the R2 device data may not be located on the same tier as the related data
on the R1 device.
FAST VP SRDF coordination allows R1 performance metrics to be used
when making promotion-and-demotion decisions for data belonging to
an R2 device.
44

SRDF coordination is Enabled or Disabled by the storage group
associated with a FAST VP policy. The default state is Disabled.
Note: FAST VP SRDF coordination requires that both the local and remote
Symmetrix array be at a code level that supports SRDF coordination.
This feature can be enabled when the storage group is associated with a
policy. It can also be enabled by modifying an existing association.
You only need to enable this feature on a storage group containing R1
devices. If it is enabled on a storage group containing R2 devices, the
setting has no effect. The only case that this would not be true is if an
SRDF swap operation occurs and converts the R2 devices to R1 devices.
FAST VP SRDF coordination is supported for single, concurrent, and
cascaded SRDF pairings in any mode of operation: Synchronous,
asynchronous, adaptive copy, SRDF/EDP, and SRDF/Star.
In the case of cascaded SRDF configurations, the R21 device acts as a
relay, transmitting the R1 metrics to the R2 device.
In the case of an R22 device, metrics will only be received across the
SRDF link that is currently active.
Note: FAST VP SRDF coordination is supported in mainframe environments
running PPRC.
Effective performance score

When enabled on a storage group, the collected FAST VP performance
metrics for R1 devices are periodically transmitted across the SRDF link
to the corresponding R2 devices.
Note: Performance metrics are only sent for R1 devices when their
corresponding R2 devices are being managed by FAST VP.
On the R2 device, the R1 performance metrics are merged with the actual
R2 metrics. This creates an effective performance score for data on the R2
devices.
When promotion-and-demotion decisions are made on the remote array,
the effective score is used for the R2 data, thereby allowing the R1
45
workload to influence the movement of the R2 data. Data that is heavily

read on the R1 device is likely to be promoted to the higher tiers in the
policy to which the R2 device is associated.
Note: The R2 devices effective performance score also influences the
calculation of promotion-and-demotion thresholds on the remote array.
SRDF coordination considerations

When the SRDF link between the R1 and R2 devices is not ready, the R1
performance metrics are not transmitted to the R2 device. When the link
is restored, the metrics are transmitted again.
The SRDF link is considered to be not ready when the SRDF pair state is
in one of the following states:
Split
Suspended
Failedover
Partitioned
During the period that the metrics are not being sent, previously
received R1 metrics are decayed in a manner similar to normally
collected performance data.
Note: For more information on decaying of performance metrics, see I/O
activity rates on page 27.
If an SRDF personality swap operation is performed, performance

metrics are only transmitted when SRDF coordination is enabled on the
storage group containing the new R1 devices.
Note: After a swap operation, performance metrics are automatically
transmitted from the new R1 devices, as long as SRDF coordination had been
previously enabled while the storage group contained R2 devices.
46

FAST VP Compression
VP Compression provides the ability to compress data belonging to thin
devices. Compressed data consumes less physical space in a thin pool,
thus providing additional space for more data to be written to the pool.
EMC compression capabilities for Virtually Provisioned and FAST VP
environments provide customers with 2:1 or greater data compression
for lightly and very infrequently accessed data. EMC defines
infrequently accessed data as that which is not accessed within monthend, quarter-end, or year-end activities, nor accessed as part of full
backup processing.
Data can be compressed manually for an individual thin device, or
group of devices, by means of Solutions Enabler and Unisphere for
VMAX.
Alternatively, inactive data belonging to thin devices managed by FAST
VP can be automatically compressed using FAST VP Compression.
Note: For more information on VP Compression, refer to the Best Practices
for Fast, Simple Capacity Allocation with EMC Symmetrix Virtual
Provisioning Technical Note, available at http://support.emc.com.
FAST VP Compression is enabled at the system level by setting the time

to compress parameter to a value between 40 and 400 days. Data that is
seen to be inactive for a period of time longer than this parameter will be
considered eligible for automatic compression. The default value for the
time to compress is never.
Automated compression
FAST VP Compression automates VP Compression for thin devices that
are managed by FAST VP. This automated compression takes place at
the sub-LUN level. Compression decisions are based on the activity level
of individual extent groups (120 tracks), similar to promotion-anddemotion decisions. However, the actual compression itself is performed
per thin device extent (12 tracks).
Extent groups that have been inactive on disk for a user-defined period
of time, known as the time to compress, will be considered eligible for
compression. The time to compress parameter can be set between 40 and
47
400 days. The default time to compress is never.

In order for thin device extent to be compressed automatically by FAST
VP, all of the following criteria must be met:
The extent must belong to an extent group that has been inactive for
a period equal to or greater than the time to compress.
The extent must be located in a thin pool that has been enabled for
compression.
The extent must compress by at least 50 percent.
Policy compliance
For the purposes of calculating a storage groups compliance with a
policy, FAST VP does not take into account any compression that has
occurred on any of the devices within the group. Only the logical,
allocated capacity consumed by the devices is considered.
For example, if 50 GB of data belonging to a storage group was demoted
to the SATA tier and subsequently compressed to only consume 20 GB,
the compliance calculation for the storage group would be based on 50
GB consumed within the SATA tier.
Pool reserved capacity
The pool reserved capacity (PRC) reserves a percentage of each pool
included in a VP tier for activities not associated with FAST VP. The PRC
is based on the actual capacity allocated within a thin pool. This applies
even if there is compressed data allocated in the pool.
Compression task execution
Extent groups are evaluated for compression at the same time extent
groups are evaluated for promotion or demotion. However,
performance-related promotions and demotions have a higher priority
than compression activity, so there may be some time lag between an
extent group becoming eligible for compression and it actually being
compressed.
48

SRDF interoperability
By default, FAST VP runs independently on each side of an SRDF link,
and movement decisions are based on the workload seen by the data
locally on each array. This applies to FAST VP Compression, too. This
means that compression decisions made on the R1 side may not
necessarily be made on the R2 side.
If FAST VP SRDF coordination is enabled for a storage group associated
with a FAST VP policy, performance metrics collected for an R1 device
are transferred to the R2, allowing the R1 workload to influence
promotion-and-demotion decisions on the R2 data.
As a part of the performance metrics collected, the length of time the
data has been inactive is also transferred. This period of inactivity on R1
data can then influence compression decisions on the corresponding R2
data.
This does not guarantee, however, that data compressed on the R1 side
will have its corresponding data compressed on the R2 side, and vice
versa.
Compression decisions on each side of the SRDF link will be influenced
by the Time to Compress parameter configured on each array, and also
by the pools that are enabled for compression.
User-defined FTS tier

By default, any external tier added to a FAST VP policy is considered to
be the lowest performing tier within the policy, even below the SATA
tier. However, depending on the configuration of the external tier, it may
be possible that the tier can provide a higher level of performance than
an internal SATA, or even FC, tier.
In the case where it is expected that an external tier will perform at a
higher level than one or more internal tiers, the relative performance
expectation can be user-defined. This will then affect the tiers ranking
amongst other tiers when added to a FAST VP policy.
49
Note: Performance of external arrays may vary under changing workloads,

especially when the external array is not fully devoted to VMAX I/O. As a
result, FAST VP may not always be able to make the optimal choices for data
placement when used with FTS-based tiers defined as other than the lowest
tier of storage.
External technology type

When an external tier is created, an optional technology type (EFD, FC,
or SATA) may be specified, in addition to the external location. By
specifying a technology type, a related expectation of performance is
associated with the tier.
For example, an external tier created with the technology type of FC will
be expected to have similar performance characteristics to that of an
internal FC tier, with some allowance for latency that may be introduced
by the SAN connectivity between the local and external storage arrays.
As such, an external FC tier will be ranked below an internal FC tier, but
above an internal SATA tier when included in a multi-tier policy.
After an external tier has been created, the technology type can be
modified. If the type is changed, the ranking of the tier will change
within any policy in which it has been included. As such, an external tier
can be upgraded or downgraded within a policy.
Note: The technology type of a tier can only be modified for an external tier.
It cannot be changed for an internal tier.
External tier performance discovery

When a technology type, other than SATA, is specified for an external
tier, the tier is potentially expected to perform at a higher level than
other tiers contained within a FAST VP policy. However, there may be
circumstances where this is not the case, and the performance
expectations cannot be met.
50
FAST VP interoperability
For example, unexpected latency in the SAN may cause the performance
of an external tier to fall below that of an internal tier of a lower-ranked
technology. Having a higher-ranked tier perform less than a lowerranked tier could potentially have an adverse affect on the behavior of
FAST VP.
To address this possibility, Enginuity executes an initial performance
discovery of the tier when it is first added to a FAST VP policy. This is
done to ensure that the performance of the external tier is in line with the
user-defined expectations. This initial performance test is known as full
discovery testing. Similar testing is performed when a change is made to
the underlying eDisks for the tier, or if the technology type is modified in
the tier definition.
Once the full performance discovery completes, an ongoing task
periodically executes a lighter performance discovery. This is known as
discovery validation testing. The purpose of this discovery is to validate, or
incrementally adjust, the previously discovered performance.
At any point, if the performance of an external tier falls below
expectations, an event is triggered, alerting users to this fact.
The event (event ID 1511) is triggered when the performance of an
external tier changes, dropping below the expected level.
Based on this alert, users can address the discrepancy between the actual
performance and the expected performance of the tier. This can be done
by either addressing the cause of the degraded performance on the
external tier, or by lowering the expectations of the tier.
FAST VP is fully interoperable with all Symmetrix replication
technologies: EMC SRDF, EMC TimeFinder/Clone, TimeFinder/Snap,
and Open Replicator. Any active replication on a Symmetrix device
remains intact while data from that device is being moved. Similarly, all
incremental relationships are maintained for the moved or swapped
devices.
FAST VP also operates alongside Symmetrix features such as Symmetrix
51
Optimizer, Dynamic Cache Partitioning, and Auto-provisioning Groups.

SRDF
Thin SRDF devices, R1 or R2, can be associated with a FAST policy.
Extents of SRDF devices can be moved between tiers while the devices
are being actively replicated, in either synchronous or asynchronous
modes.
Note: For more information on using FAST VP with SRDF, see FAST VP
SRDF coordination on page 44.
TimeFinder/Clone
Both the source and target devices of a TimeFinder/Clone session can be
managed by FAST VP. However, the source and target are managed
independently, and, as a result, may end up with different extent
allocations across tiers.
TimeFinder/Snap
The source device in a TimeFinder/Snap session can be managed by
FAST VP. However, the target device (VDEV) may not be brought under
FAST VP control.
TimeFinder VP Snap
The source device in a TimeFinder VP Snap session can be managed by
FAST VP. Target devices may also be managed by FAST VP. However,
target devices that contain shared allocations will not have data moved
between tiers.
Open Replicator
The control device in an Open Replicator session, push or pull, can have
extents moved by FAST VP.
Virtual Provisioning
Each thin device, whether under FAST VP control or not, may only be
bound to a single thin pool. All host-write-generated allocations, or user-
52
requested pre-allocations, are performed on this pool. FAST VP data
movements do not change the binding information for a thin device.
It is possible to change the binding information for a thin device without
changing any of the current extent allocations for the device. However,
when rebinding a device that is under FAST VP control, the thin pool the
device is being rebound to must belong to one of the VP tiers contained
in the policy with which the device is associated.
Virtual Provisioning space reclamation
Space reclamation may be run against a thin device under FAST VP
control. However, during the space-reclamation process, the sub-LUN
performance metrics are not updated, and no data movements are
performed.
Note: If FAST VP is actively moving extents of a device, a request to reclaim
space on that device will fail. Prior to issuing the space-reclamation task, the
device should first be pinned. Pinning a device suspends any active FAST VP
data movements for the device and allows the request to succeed.
Virtual Provisioning T10 unmap

Unmap commands can be issued to thin devices under FAST VP control.
The T10 SCSI unmap command for thin devices advises a target thin
device that a range of blocks are no longer in use. If this range covers a
full thin device extent, then that extent can be deallocated, and the free
space is returned to the pool.
If the unmap command range covers only some tracks in an extent, those
tracks are marked Never Written by Host (NWBH). The extent is not
deallocated. However, those tracks do not have to be retrieved from the
drive should a read request be performed. Instead, the Symmetrix array
immediately returns all zeros.
Note: The T10 SCSI unmap command is only supported in Open Systems
(FBA) environments.
Virtual Provisioning pool management

Data devices may be added to or removed from a thin pool that is in the
FAST VP tier. Data movements related to FAST VP, into or out of the
53
thin pool, continue while the data devices are being modified.
When adding data devices to a thin pool, pool rebalancing may be run.
Similarly, when disabling and removing data devices from the pool, they
drain their allocated tracks to other enabled data devices in the pool.
While running either data-device draining or automated pool
rebalancing on a thin pool that is included in a VP tier is allowed, both
processes may affect performance of FAST VP data movements.
Virtual LUN VP mobility
A thin device under FAST VP control may be migrated using VLUN VP.
Such a migration results in all allocated extents of the device being
moved to a single thin pool.
While the migration is in progress, no FAST VP related data movements
are performed. Once the migration is complete, all allocated extents of
the thin device will be available to be retiered.
To prevent the migrated device from being retiered by FAST VP
immediately following the migration, it is recommended that the device
first be pinned. The device can later be unpinned to re-enable FAST VPrelated data movements.
FAST
Both FAST and FAST VP may coexist within a single Symmetrix array.
FAST only performs full-device movements of non-thin devices. As a
result, there is no impact to FAST VPs management of thin devices.
Both FAST and FAST VP share some configuration parameters. These
are:
54
Performance Time Windows
Symmetrix Optimizer
Symmetrix Optimizer operates only on non-thin devices. As such, there
is no impact on FAST VPs management of thin devices.
Both Optimizer and FAST VP share some configuration parameters.
These are:
Performance Time Windows
Dynamic Cache Partitioning

Dynamic Cache Partitioning (DCP) can be used to isolate storage
handling of different applications. As data movements use the same
cache partition as the application, movements of data on behalf of one
application do not affect the performance of applications that are not
sharing the same cache partition.
FBA Auto-provisioning Groups
Storage groups created for the purposes of Auto-provisioning FBA
devices may also be used for FAST VP. However, while a device may be
contained in multiple storage groups for the purposes of Autoprovisioning, the device may only be contained in one storage group that
is associated with a FAST policy (DP or VP).
If a storage group contains a mix of device types, thin and non-thin, only
the devices matching the type of FAST policy the group is associated
with are managed by FAST.
If it is intended that both device types in an Auto-provisioning storage
group be managed by FAST and FAST VP, then separate storage groups
need to be created. A storage group with the non-thin devices may then
be associated with a policy containing DP tiers. A separate storage group
containing the thin devices needs to be associated with a policy
containing VP tiers.
If separate storage groups are created for the purposes of applying
separate FAST policies, then these groups can be added to a parent
storage group, using the cascaded SG feature. A masking view can then
be applied to the parent SG, provisioning both sets of devices.
55
Best practice considerations and recommendations
Note: FAST policies may only be associated to storage groups containing

devices. A parent SG, containing other storage groups, cannot be associated
to a FAST policy.

The following sections detail best practice recommendations for
planning the implementation of a FAST VP environment.
The best practices documented are based on features available in
Enginuity 5876.268.174, Solutions Enabler V7.6.2, and Unisphere for
VMAX 1.6.2.
FAST VP configuration parameters

FAST VP has multiple configuration parameters that control its behavior.
These include settings to determine the effect of past workloads on data
analysis, quality of service for data movements, and pool space to be
reserved for activities not associated with FAST VP. Also, performancecollection and data-movement time windows can be defined.
The following sections describe best practice recommendations for each
of these configuration parameters.
Note: For more information on each of these configuration parameters, refer
to the Implementing Fully Automated Storage Tiering for Virtual Pools
(FAST VP) for EMC Symmetrix VMAX Series Arrays Technical Note
available at http://support.emc.com.

The performance time windows specify date and time ranges what
collected performance metrics should be included, or not, for the
purposes of FAST VP performance analysis. By default, performance
metrics are collected 24 hours a day, every day. Time windows may be
56

defined, however, to include only certain times of day or days of the
week, as well as exclude other time periods.
While the performance time window is open, in addition to performance
metrics being collected, the long-term and short-term activity rates are
also being incremented and decayed. As such, the performance time
window can greatly influence the performance scores of data.
For example, if some data is only busy during production hours of 8 a.m.
to 8 p.m., limiting the performance time window to just these hours can
cause the data accessed during production hours to much higher scores
than the default 24-hour window.
As a best practice, the performance time windows should be configured
to target the specific workloads the user wishes to optimize. For
example, if the normal production workload typically occurs between 8
a.m. and 8 p.m. on weekdays then the performance time windows
should be configured to match these periods.
Similarly, if the workload on weekends or during holiday periods, are
not as important or representative of the other days; you should consider
excluding them from the performance time window.
Note: The performance time window is applied system-wide. If multiple
applications are active on the array, but active at different times, including
weekends, then the default performance time window behavior should be
left unchanged.

Data movement time windows are used to specify date and time ranges
when data movements are allowed, or not allowed, to be performed.
The best practice recommendation is that, at a minimum, the data
movement window should allow data movements for the same period of
time that the performance time windows allow data collection. This
allows FAST VP to react quickly and dynamically to any changes in
workload that occur on the array.
Unless there are specific time periods to avoid data movements, during a
backup window, for example, it may be appropriate to set the data
movement window to allow FAST VP to perform movements 24 hours a
57
day, every day.

Note: If there is a concern about possible impact of data movements
occurring during a production workload, the FAST VP Relocation Rate can
be used to minimize this impact.

The Workload Analysis Period (WAP) determines the degree to which
FAST VP metrics are influenced by recent host activity, and also lessrecent host activity, that takes place while the performance time window
is considered open.
The longer the time defined in the WAP, the greater the amount of
weight is assigned to less-recent host activity.
Lowering the WAP may allow FAST VP to react to changes in workload
more quickly, but may lead to greater amounts of data being moved
between tiers.
The influence of the WAP setting is applied only when the performance
time window is open. For example, if the performance time window is
left at the default (open 24 hours a day, 7 days a week), the default WAP
(one week) will cover one calendar week. However, if the performance
window is configured to be open 12 hours a day, 7 days a week, the
default WAP will actually incorporate two calendar weeks.
The best practice recommendation for the Workload Analysis Period is
to match it to the performance time window to cover one calendar week.
The Initial Analysis Period (IAP) defines the minimum amount of time a
thin device should be under FAST VP management before any data
movements are performed.
This parameter should be set to a value that allows sufficient data
samples for FAST VP to establish a good characterization of the typical
workload on that device.
58

At the initial deployment of FAST VP, it may make sense to set the IAP
to 168 hours (one week) to ensure that a typical weekly workload cycle is
seen. However, once FAST VP data movement has begun, you may
reduce the IAP to 24 hours (one day), which allows the newly associated
devices to benefit from FAST VP movement recommendations more
quickly.
FAST VP Relocation Rate
The FAST VP Relocation Rate (FRR) is a quality of service (QoS) setting
for FAST VP. The FRR affects the aggressiveness of data-movement
requests generated by FAST VP. This aggressiveness is measured as the
amount of data that is requested to be moved at any given time, and the
priority given to moving the data between pools.
Setting the FRR to the most aggressive value, 1, causes FAST VP to
attempt to move the most data it can, as quickly as it can. Depending on
the amount of data to be moved, an FRR of 1 is more likely to impact
host I/O response times, due to the additional back-end overhead being
generated by the FAST VP data movements. However, the distribution
of data across tiers completes in a shorter period of time.
Setting the FRR to the least aggressive value, 10, causes FAST VP to
greatly reduce the amount of data that is moved, and the pace at which it
moves. This setting causes no impact to host I/O response time, but the
final redistribution of data across tiers takes longer.
Figure 1 shows the same workload, 1,500 IOPS of type OLTP2, being run
on an environment containing two FAST VP tiers, Fibre Channel (FC)
and Enterprise Flash (EFD). The same test was carried out with three
separate relocation rates: 1, 5, and 8.
With a FRR of 1, an initial increase in response time is seen at the twohour mark, when FAST VP data movement began, while no increase in
response time is seen when the relocation rate is set to 8. However, the
steady state for the response time is seen in a much shorter period of
time for the lower, more aggressive, setting.
59
Figure 9. Example workload with varying relocation rates

The default value for the FRR is 5. However, the best practice
recommendation for the initial deployment of FAST VP is to start with a
more conservative value for the relocation rate, perhaps 7 or 8. The
reason for this is that when FAST VP is first enabled, the amount of data
to be moved is likely to be greater, compared to when FAST VP has been
running for some time.
At a later date, when it is seen that the amount of data movements
between tiers is less, the FRR can be set back to the default value of 5.
This allows FAST VP to adjust to small changes in the workload more
quickly.
Pool Reserved Capacity
The Pool Reserved Capacity (PRC) reserves a percentage of each pool
included in a VP tier for activities not associated with FAST VP. When
60

the percentage of unallocated space in a thin pool is equal to the PRC,
FAST VP no longer performs data movements into that pool.
The PRC can be set both as a system-wide setting and for each individual
pool. If the PRC has not been set for a pool, or the PRC for the pool has
been set to NONE, then the system-wide setting is used.
For the system-wide setting, the best practice recommendation is to use
the default value of 10 percent.
For individual pools, if thin devices are bound to the pool, the best
practice recommendation is to set the PRC based on the lowest allocation
warning level for that thin pool. For example, if a warning is triggered
when a thin pool has reached an allocation of 80 percent of its capacity,
then the PRC should be set to 20 percent. This ensures that the remaining
20 percent of the pool is only used for new host-generated allocations,
and not FAST VP data movements.
If no thin devices are bound to the pool, or are going to be bound, then
the PRC should be set to the lowest possible value, 1 percent.
Note: In an environment where only two tiers are configured in the VMAX
storage array, and VP allocation by FAST policy is enabled, it may be
beneficial to set the PRC to 1 percent for all thin pools.

The VP Allocation by Fast Policy feature allows new allocations to come
from any of the thin pools included in the FAST VP policy to which the
thin device is associated.
With this feature enabled, FAST VP attempts to allocate new writes in
the most appropriate tier first, based on available performance metrics. If
no performance metrics are available, the allocation is attempted in the
pool to which the device is bound.
If the pool initially chosen to allocate the data is full, FAST VP looks to
other pools contained within the FAST VP policy and allocates from
there. As long as there is space available in at least one of the pools
within the policy, all new extent allocations will be successful.
The allocation by policy feature is enabled at the Symmetrix array level
and applies to all allocations for all devices managed by FAST VP. The
61
feature is either Enabled or Disabled (the default setting is Disabled).

When disabled, new allocations only come from the pool to which the
thin device is bound.
As a best practice, it is recommended that VP Allocation by FAST Policy
be enabled.
Note: For more information on the decision making process of the VP
allocation by FAST policy feature, refer to the Advance FAST VP features
section of the Implementing Fully Automated Storage Tiering for Virtual
Pools (FAST VP) for EMC Symmetrix VMAX Series Arrays Technical Note.
FAST VP tier configuration

A Symmetrix storage tier is a specification of a set of resources of the
same disk technology type (EFD, FC/SAS, SATA, or FTS storage),
combined with a given RAID protection type (RAID 1, RAID 5, RAID 6,
or Unprotected), and the same emulation (FBA or CKD).
Note: The Unprotected RAID type may only be applied to a tier residing on
an FTS-connected storage array.
FAST VP tiers can contain between one and four thin storage pools. To be
included in a FAST VP tier, a thin pool must contain data devices
configured on the same drive technology and emulation (and the same
rotational speed, in the case of FC, SAS, and SATA drives).
To combine multiple pools in a single tier, the pools must be of the same
RAID protection and configured on the same drive technology.
When a tier contains multiple pools, FAST VP movements into the tier
will be striped across all pools within the tier.
Drive-speed considerations
Two or more thin pools containing data devices configured on rotating

drives of different speeds, but of the same drive technology, may be
combined in a single VP tier. This is not recommended, however, as
62

there is the potential for uneven performance across the tier due to the
difference in drive speeds.
Drive-size considerations
Drive size is not a factor when adding data devices to a thin pool. For
example, data devices configured on 300 GB FC 15 k drives can coexist in
a pool with data devices configured on 600 GB FC 15 k drives.
It is not recommended to combine drives of different sizes into the same
tier. The larger drives will ultimately contain more data than the smaller
drives. As such, they are likely to see a larger I/O workload than the
smaller drives, which may lead to different performance levels on data
devices across the tier.
If combining data devices on different drive sizes in the same storage tier
cannot be avoided, it is recommended to create separate pools for each
drive size, and then combine those pools into a single tier.
Note: For more information on best practices for configuring thin pools, refer
to the Best Practices for Fast, Simple Capacity Allocation with EMC
Symmetrix Virtual Provisioning Technical Note, available at
http://support.emc.com.
External tiers
External tiers can only be configured on storage configured for external

provisioning. Encapsulated storage is not supported by FAST VP.
When creating a tier on an external array, it is highly recommended that
the same best practices for the creation of internal thin pools and tiers be
followed for external pools and tiers. Primarily, external thin pools
should be configured on eDisks with similar performance profiles.
Note: For more information on best practices for configuring eDisks, refer to
the Design and Implementation Best Practices for EMC Symmetrix Federated
Tiered Storage (FTS) Technical Note, available at http://support.emc.com.
To that end, external thin pools should be created on eDisks from a

single external storage array. These eDisks should also be configured on
external LUNs of the same RAID protection and configured on the same
drive technology.
63
Similarly, if two or more external thin pools are added to an external tier,
the external pools should be configured on the same external array,
sharing the same RAID protection and drive technology type.
Greater care must be taken, however, in creating external pools and tiers.
The reason for this is that the Symmetrix array has no visibility into the
RAID protection or the drive technology of the external LUNs. As such,
there are no software protections to ensure that all the eDisks in a disk
group follow the rules that are applied to internal thin pools and tiers.
User-defined technology type
Depending on the configuration of the external tier (external RAID

protection and technology type), it may be possible that the tier can
provide a higher level of performance than an internal SATA, or possibly
an internal FC, tier.
In the case where it is expected that an external tier will perform at a
higher level than one or more internal tiers, the relative performance
expectation can be user-defined by specifying the technology type that
equates to the expected performance.
When the external tier is first added to a FAST VP policy, the Symmetrix
array executes a performance discovery in order to evaluate if the actual
performance is in line with the user-defined expectations.
Because of this performance discovery, it is recommended that external
tiers by added to a FAST VP policy at times when host workload is
relatively light. In this way, the full-discovery workload will compete
less with host workload.
Similarly, the external tier should also be added to the FAST VP policy as
early as is practical, prior to host applications accessing the external
storage.
FAST VP policy configuration
A FAST VP policy groups between one and four VP tiers and assigns an
upper-usage limit for each storage tier. The upper limit specifies the
64

maximum amount of capacity a storage group associated with the policy
can use on that particular tier. The upper-capacity usage limit for each
storage tier is specified as a percentage of the configured, logical capacity
of the associated storage group.
The usage limit for each tier must be between 1 percent and 100 percent.
When combined, the upper-usage limit for all thin storage tiers in the
policy must total at least 100 percent, but may be greater than 100
percent.
Tier ranking
FAST VP ranks tiers within a policy based on known performance

models. Tiers are ranked based on the drive technology of the pools
within the each tier (EFD, FC, or SATA), as well as the location of the tier
(internal or external).
Tier usage limits
Creating a policy with a total upper-usage limit greater than 100 percent
allows flexibility with the configuration of a storage group, whereby data
may be moved between tiers without necessarily having to move a
corresponding amount of other data within the same storage group.
The default FAST VP policy would be to specify 100 percent for each of
the included tiers. Such a policy can provide the greatest amount of
flexibility to an associated storage group, as it allows 100 percent of the
storage groups capacity to be promoted or demoted to any tier within
the policy, as appropriate.
Operationally, it may not be appropriate to deploy the 100/100/100
policy. There may be reasons to limit access to a particular tier within the
array.
As an example, it may be appropriate to limit the amount of a storage
groups capacity that can be placed on EFD. This may be used to prevent
one single storage group, or application, from consuming all of the EFD
resources. In this case, a policy containing just a small percentage for
EFD would be recommended.
65
Note: Care must also be taken, however, to not set the policy percentage too
low for the higher-performing tiers in a policy. A percentage that is too low
may force FAST VP to leave active data on a lower tier, potentially
overloading that tier.
Similarly, it may be appropriate to restrict the amount of SATA capacity

a storage group may utilize. Some applications, which can become
inactive from time to time, may require a minimum level of performance
when they become active again. For such applications, a policy excluding
the SATA tier could be appropriate.
The best way to determine appropriate policies for a FAST VP
implementation is to examine the workload skew for the application
data to be managed by FAST VP. The workload skew defines an
asymmetry in data usage over time. This means a small percentage of the
data on the array may be servicing the majority of the workload on the
array. One tool that provides insight into this workload skew is Tier
Advisor.
Tier Advisor
Tier Advisor is a utility available to EMC technical staff that estimates

the performance and cost of mixing drives of different technology types
(EFD, FC, and SATA) within Symmetrix VMAX Family storage arrays.
Tier Advisor can examine performance data collected from Symmetrix,
VNX, or CLARiiON storage arrays and determine the workload skew
at the full LUN level. It can also estimate the workload skew at the subLUN level.
With this information, Tier Advisor can model an optimal storage-array
configuration by enabling the ability to interactively experiment with
different storage tiers and storage policies, until achieving the desired
cost and performance preferences.
66

Thin device binding
Each thin device, whether under FAST VP control or not, may only be
bound to a single thin pool. By default, all host-write-generated
allocations, or user-requested pre-allocations, are performed from this
pool.
From an ease-of-management and reporting perspective, it is
recommended that all thin devices be bound to a single pool within the
Symmetrix array.
Note: FAST VP data movements do not change the binding information for a
thin device.
In determining the appropriate pool, both performance requirements

and capacity management should be taken into consideration, as well as
the use of thin device pre-allocation and the system write-pending limit.
Note: Unless there is a very specific performance need, it is not
recommended to bind thin devices under FAST VP control to a thin pool in
the EFD tier.
Performance consideration
With VP allocation by FAST policy enabled, FAST VP attempts to

allocate new extents in the most appropriate tier. This is based on
available performance metrics for the thin device being allocated. Should
performance metrics not be available, the allocation comes from the pool
to which the thin device is bound.
As a result, the best practice recommendation is to bind all thin devices
to a pool within the FC tier in the policy.
Capacity-management consideration
Binding all thin devices to a single pool ultimately causes that single
pool to be oversubscribed. If the allocation by policy feature is not
enabled, this could potentially lead to issues as the pool fills up. Host
writes to unallocated areas of a thin device will fail if there is insufficient
space in the bound pool.
In an EFD, FC, SATA configuration, if the FC tier is significantly smaller
than the SATA tier, binding all thin devices to the SATA tier reduces the
67
likelihood of the bound pool filling up.

If performance needs require the thin devices to be bound to FC, the Pool
Reserved Capacity or the FAST VP policy configuration, or a
combination of both, can be used to alleviate a potential pool-full
condition.
Note: Enabling VP allocation by FAST policy on the Symmetrix VMAX array
greatly alleviates the capacity-management consideration.
Pre-allocation
A way to avoid writes to a thin device failing due to a pool being fully
allocated is to pre-allocate the thin device when it is bound. However,
performance requirements of newly written data should be considered
prior to using pre-allocation.
When FAST VP performs data movements, only allocated extents are
moved. This applies not only to extents allocated as the result of a host
write, but also to extents that have been pre-allocated. These preallocated extents will be moved even if no data has yet been written to
them.
Note: When moving pre-allocated, but unwritten, extents, no data is actually
moved. The pointer for the extent is simply redirected to the pool in the
target tier.
Pre-allocated, but unwritten, extents show as inactive and, as a result, are

demoted to the lowest tier included in the associated FAST VP policy.
When these extents are eventually written to, the write performance will
be that of the tier it has been demoted to.
A best-practice recommendation is to not pre-allocate thin devices
managed by FAST VP. Pre-allocation should only be used selectively for
those devices that can never tolerate a write failure due to a full pool.
68

System write-pending limit
FAST VP is designed to throttle back data movements, both promotions

and demotions, as the write-pending count approaches the system writepending limit. This throttling gives an even higher priority to host I/O to
ensure that tracks marked as write pending are destaged appropriately.
Note: By default, the system write-pending limit on a Symmetrix VMAX
array is set to 75 percent of the available cache.
If the write-pending count reaches 60 percent of the write-pending limit,

FAST VP data movements stop. As the write-pending count decreases
below this level, data movements automatically restart.
A very busy workload running on SATA disks, with SATA disks at or
near 100 percent utilization, causing a high write-pending count, impacts
FAST VP from promoting active extents to FC or EFD tiers.
In an environment with a high write workload, it is recommended to
bind thin devices to a pool in the FC tier.
Note: If a large amount of write activity is being seen on the SATA tier, it
may be worth considering placing the DATA devices configured on SATA
into a separate dynamic cache partition. Doing so could prevent an increase
in the write-pending count and alleviate any impact on FAST VP and the
storage array as a whole.
Rebinding a thin device
It is possible to change the binding information for a thin device without

moving any of the current extent allocations for the device. This is done
by a process called rebinding.
Rebinding a thin device increases the subscription level of the pool to
which the device is bound, and decreases the subscription level of the
pool to which it was previously bound. However, the allocation levels in
both pools remain unchanged.
Note: When rebinding a device that is under FAST VP control, the thin pool
to which the device is being rebound must belong to one of the VP tiers
contained in the policy to which the device is associated.
69
Thin pool oversubscription

Thin pool oversubscription allows an organization to present larger than
needed devices to hosts and applications without having to purchase
enough physical drives to fully allocate all of the space represented by
the thin devices.
Note: For more information on oversubscription, refer to the Best Practices
for Fast, Simple Capacity Allocation with EMC Symmetrix Virtual
In a FAST VP configuration, the capacity available for thin devices is

now spread across multiple pools. Even if there is no plan to
oversubscribe the available capacity in the Symmetrix array, there
typically is insufficient space in a single tier to accommodate the
configured thin device capacity.
By following the previous recommendation, binding all thin devices
being managed by FAST VP to a single thin pool inherently causes that
pool to be oversubscribed. As a result, the oversubscription limit for that
pool needs to be set to a value greater than 100 percent.
Available capacity
To determine the level to set the oversubscription limit, the total capacity
available to devices under the control of FAST VP should first be
calculated.
If the VP Allocation by FAST Policy feature is enabled, then 100 percent
of the capacity of each pool within the policy is available.
If the allocation by policy feature is not enabled, the following points
should be considered:
70
For pools with thin devices bound, 100 percent of the

capacity is available.
For pools with no thin devices bound, 100 percent of the

pool, less the capacity reserved by the PRC, is available.
Note: The pool reserved capacity value only affects FAST VP movements into
the pool. The PRC does not affect the ability for the thin devices to allocate
extents within the pool.
Oversubscription limits
After determining the capacity available to FAST VP, an

oversubscription limit can then be calculated for the pool devices that are
going to be bound to it.
To ensure the configured capacity of the array is not oversubscribed, the
limit can be calculated by dividing the capacity of the thin pool being
used for binding into the available capacity of all the pools. This value is
then multiplied by 100 to get a percent value.
For example, consider a configuration with a 1 TB EFD pool, a 5 TB FC
pool, and a 10 TB SATA pool. The total available capacity is 16 TB. If all
thin devices are bound to FC, the oversubscription limit could be set to
320% (16/5)*100.
This value can be set higher if the intention is to initially oversubscribe
the configured physical capacity of the array, and then add storage on an
as-needed basis.
For thin pools where devices will never be bound, the subscription limit
can be set to 0 percent. This prevents any accidental binding or migration
to that pool.
RAID protection considerations
When designing a Virtual Provisioning configuration, and particularly
when choosing a corresponding RAID protection strategy, both devicelevel performance and availability implications should be carefully
considered.
Note: For more information on these considerations, refer to the Best
Practices for Fast, Simple Capacity Allocation with EMC Symmetrix Virtual
FAST VP does not change these considerations and recommendations

from a performance perspective. What FAST VP does change, however,
is that a single thin device can now have its data spread across multiple
71
tiers of varying RAID protection and drive technology within the array.
Because of this, the availability of an individual thin device is not based
just on the availability characteristics of the thin pool to which the device
is bound. Instead, availability is based on the characteristics of all the
tiers in which it may have extents.
While performance and availability requirements ultimately determine
the configuration of each tier within the Symmetrix array, it is
recommended as a best practice to choose RAID 1 or RAID 5 (preferably
3+1) protection on EFDs. The faster rebuild times of EFDs provide higher
availability for these protection schemes on that tier.
Also, it is recommended to use either RAID 1 or RAID 6 (preferably 6+2)
on the SATA tier. This is due to the slower rebuild times of the SATA
drives (compared to EFD and FC), and the increased chance of a dualdrive failure, leading to data unavailability with RAID 5 protection.
For the FC tier, RAID 1 is the recommended protection level. Mirrored
data devices on FC pools provide a higher level of performance than
both RAID 5 and RAID 6, particularly for write workloads. Availability
of RAID 1, in regard to a dual-drive failure, is also greater than RAID 5.
To obtain the best availability numbers for RAID 1 on FC, the use of
lower-capacity drives is recommended.
Note: For new environments being configured in anticipation of
implementing FAST VP, or for existing environments adding more tiers, it is
highly recommended that an EMC representative be engaged to assist in
determining the appropriate RAID protection schemes for each tier.
Drive configuration
For most customer configurations, the best-practice configuration
guidelines recommend an even, balanced distribution of physical disks
across the disk adapters (DAs) and DA CPUs.
72

This is of particular relevance for EFDs, which are each able to support
thousands of I/Os per second, and, therefore, are able to create a load on
the DA equivalent to that of multiple hard disk drives.
An even distribution of I/O across all DA CPUs is optimal to maximize
their capability and the overall capability of the Symmetrix array.
Generally, it is appropriate to configure more, smaller drives, than fewer,
larger drives for both EFD and FC tiers. Doing so spreads I/O load as
wide as possible across the Symmetrix back-end.
Storage group configuration
In order to provide the most granular management of applications
controlled by FAST VP, it is recommended that each application be
placed in its own storage group to be associated to a policy. This
provides for more equitable management of FAST VP tiers utilization.
Because the tier usage limits in a policy apply to the total configured
capacity within a storage group, placing the devices for multiple
applications in a single storage group may allow one application to
obtain more of a specific tier than is really desired.
Cascaded storage groups
In some cases, there may be a need to separately manage different device

types within a single application. For example, it may be desired to
apply different FAST policies to both the redo log devices and the data
file devices within a database application. To accomplish this, cascaded
storage groups can be used.
Cascaded storage groups allow devices to be placed in separate child
storage groups which can then be associated with the same parent
storage group. Separate FAST policies can be associated with each child
storage group, while the parent storage group is used in a masking view
for the purposes of provisioning the devices to host.
As additional capacity is added to the application by way of adding
devices, the devices may be added to the appropriate child storage group
(based on the desired FAST policy). Upon adding the devices to a child
storage group, they will be automatically mapped and masked based on
the parent storage groups masking view.
73
Note: Moving a device from one child storage group to another is not
permitted if both storage groups are associated with a policy. Similarly, a
move between children is not permitted if the parent is part of a masking
view.
Storage group moves
It is possible to move a device from one storage group to another,

however, there are situations where this movement is restricted.
A device may not be moved from one storage group to another if both
the source and target group are associated with FAST policies. To
complete such a move, the device must first be removed from the source
storage group and then added to the target.
This also applies to child storage groups sharing the same parent.
Note: Removing a device from a FAST associated storage group and adding
it to another will cause the initial analysis period for that device to be reset.
No FAST data moves will occur for that device until the initial analysis
period expires.
Similarly, devices may not be moved from one storage group to another
when both storage groups are contained within a masking view. This
also applies to movement between child storage groups who share the
same parent where the parent is part of a masking view. To complete
such a move, devices will need to be removed from the source storage
group and then added to the target group.
Note: Removing a device from a storage group contained within a masking
view, or from a child where the parent is in a masking view, will cause the
host to lose access to that device.
In more dynamic environments, where the performance needs of

individual devices may change over time, and may need to be associated
to different FAST policies over time, it is recommended that two separate
sets of storage groups be maintained. One set of storage groups should
74

be used for provisioning purposes within masking views, while the
second set is used for the purposes of FAST management.
Care should be taken in such a configuration, however. When a new
device is added to an application and added to the storage group
contained within the masking view, a second operation will be needed to
add the device to the appropriate storage group for FAST management.
Storage group priority
When a storage group is associated with a FAST policy, a priority value

must be assigned to the storage group. This priority value can be
between 1 and 3, with 1 being the highest priority. The default is 2.
The best-practice recommendation is to use the default priority of 2 for
all storage groups associated with FAST VP policies. These values may
then be modified if it is seen, for example, that a high-priority
application is not getting sufficient resources from a higher tier.
SRDF
FAST VP has no restrictions in its ability to manage SRDF devices,
however, what must be considered is that data movements are restricted
to the array upon which FAST VP is operating. By default, there is no
coordination of data movements; FAST VP acts independently on both
the local and remote arrays. However, enabling FAST VP SRDF
coordination allows R1 performance metrics to be used when making
promotion-and-demotion decisions for data belonging to an R2 device.
Note: For more information on the operation of FAST VP SRDF coordination,
see FAST VP SRDF coordination on page 44.
As a general best practice, FAST VP should be employed for both R1 and

R2 devices, particularly if the remote R2 array has also been configured
with tiered storage capacity. Where possible, similar FAST VP tiers and
policies should be configured at each site.
When available, FAST VP SRDF coordination should be enabled for each
storage group containing SRDF devices that is associated with a FAST
VP policy.
Each SRDF configuration, however, presents its own unique behaviors
and workloads. Prior to implementing FAST VP in an SRDF
75
environment, the information in the following sections should be

considered.
Note: The following sections assume that SRDF is implemented with all
Symmetrix arrays configured for Virtual Provisioning (all SRDF devices are
thin devices) and capable of running FAST VP.
FAST VP behavior
For SRDF R1 devices, FAST VP promotes and demotes extent groups

based on the read-and-write activity experienced on the R1 devices.
Meanwhile, by default, the SRDF R2 devices typically only experience
write activity during normal operations. As a result, FAST VP is likely to
promote only R2 device extents that are experiencing writes.
If there are R1 device extents that only experience read activity, no
writes, then the corresponding extents on the R2 devices will see no I/O
activity. This will likely lead to these R2 device extents being demoted to
the SATA tier, assuming this was included in the FAST VP policy.
SRDF coordination changes this default behavior by periodically
transmitting FAST VP performance metrics collected for R1 devices
across the SRDF link to the corresponding R2 devices. On the R2 device,
the R1 performance metrics are merged with the actual R2 metrics.
Movement decisions made by FAST VP for these R2 devices are then
based on the merged performance metrics. In this way, read activity on
the R1 device can be reflected on the R2.
SRDF operating mode
EMC best practices, for both synchronous and asynchronous modes of

SRDF operation, recommend implementing a balanced configuration on
both the local (R1) and remote (R2) Symmetrix arrays. Ideally, data on
each array would be located on devices configured with the same RAID
protection type, on the same drive type.
76

As FAST VP operates independently on each array, and also promotes
and demotes data at the sub-LUN level, there is no guarantee that such a
balance may be maintained.
In SRDF synchronous (SRDF/S) mode, host writes are transferred
synchronously from R1 to R2. These writes are only acknowledged by
the host when the data has been received into cache on the remote R2
array. These writes to cache are then destaged asynchronously to disk on
the R2 array.
Note: For more information on SRDF/S, see the EMC Solutions Enabler
Symmetrix SRDF Family CLI Product Guide, available at
In an unbalanced configuration, where the R2 data resides on a lowerperforming tier than on the R1, performance impact may be seen at the
host if the number of write pendings builds up and writes to cache are
delayed on the R2 array.
With FAST VP, this typically does not cause a problem, as the
promotions that occur on the R2 side are the result of write activity.
Areas of the thin devices under heavy write workload are likely to be
promoted and maintained on the higher-performing tiers on the R2
array.
To avoid potential problems with the configuration becoming
unbalanced, it is recommended that FAST VP SRDF coordination be
enabled in SRDF/S environments.
In SRDF asynchronous (SRDF/A) mode, host writes are transferred
asynchronously in predefined time periods or delta sets. At any given
time, there are three delta sets in effect: The capture set, the
transmit/receive set, and the apply set.
Note: For more information on SRDF/A, see the EMC Solutions Enabler
Symmetrix SRDF Family CLI Product Guide, available at
A balanced SRDF configuration is more important for SRDF/A, as data

cannot transition from one delta set to the next until the apply set has
completed destaging to disk. If the data resides on a lower-performing
77
tier on the R2 array, compared to the R1, then the SRDF/A cycle time
may elongate and eventually cause the SRDF/A session to drop.
This is similar to SRDF/S mode in most environments, so this may not
be a large issue, as the data under write workload is promoted and
maintained on the higher-performing tiers.
To avoid potential problems with the configuration becoming
unbalanced, it is strongly recommended that FAST VP SRDF
coordination be enabled in SRDF/A environments.
SRDF/A DSE (delta set extension) should be considered to prevent
SRDF/A sessions from dropping in situations where writes propagated
to the R2 array are being destaged to a lower tier, potentially causing an
elongation of the SRDF/A cycle time.
Note: For more information on SRDF/DSE, see the Best Practices for EMC
SRDF/A Delta Set Extension Technical Note, available at
SRDF failover
As FAST VP works independently on both the R1 and R2 arrays, it

should be expected that the data layout will be different on each side if
SRDF coordination is not enabled. When an SRDF failover operation is
performed, and host applications are brought up on the R2 devices, it
should then also be expected that the performance characteristics on the
R2 will be different from those on the R1.
In this situation, it takes FAST VP some period of time to adjust to the
change in workload and start promotion-and-demotion activities based
on the mixed read-and-write workload.
To better prepare for a failover, and to shorten the time period to achieve
an adjustment to the new workload, FAST VP SRDF coordination should
be enabled.
78
Note: FAST VP performance metrics are only transmitted from R1 to R2.

When failed over, and with applications are running on R2 devices,
performance metrics will not be sent from R2 to R1.
Personality swap
An SRDF personality swap follows a similar pattern of behavior to an

SRDF failover scenario. Applications are brought up on the devices that
were formerly R2 devices.
For performance metrics to be transmitted from the new R1 devices to
the corresponding R2 devices, SRDF coordination needs to be enabled on
the storage groups containing the R1 devices.
SRDF coordination can be enabled in advance on a storage group
containing R2 devices. However, the setting only takes effect when a
personality swap is performed, converting the R2 devices to R1.
SRDF bi-directional
Best-practice recommendations change slightly in a bi-directional SRDF

environment. In this case, each Symmetrix array has both R1 and R2
devices configured.
With SRDF coordination enabled, it is possible that data belonging to an
R2 device could displace data belonging to an R1 device on a higher tier.
This may happen if the R2 devices corresponding R1 device has a higher
workload than the local R1 device.
In this scenario, it is recommended to reserve the EFD tier for R1 device
usage. This can be done by excluding any EFD tiers from the policies
associated with the R2 devices.
Should a failover be performed, then the EFD tier can be added
dynamically to the policy associated with the R2 devices. Alternatively,
the storage group containing the R2 devices could be reassociated with a
policy containing EFD.
Note: This recommendation assumes that the lower tiers are of sufficient
capacity and I/O capability to handle the expected SRDF write workload on
the R2 devices.
79
EFD considerations
If there is a smaller EFD configuration on the remote array, it is

recommended not to include the EFD tier in the FAST VP policies on the
R2 array. Similarly, if the EFD configuration on the R2 array does not
follow the best-practice guideline of being balanced across DAs, do not
include the EFD tier on the R2 side.
Note: This recommendation assumes that the lower tiers are of sufficient
capacity and I/O capability to handle the expected SRDF write workload on
the R2 devices.
FAST VP Compression
FAST VP Compression automates VP compression for thin devices that
are managed by FAST VP.
The behavior of FAST VP Compression is controlled by two
configuration parameters: FAST VP Time to Compress and FAST VP
Compression Rate. FAST VP Compression also requires that at least one
tier within the policy contains at least one thin pool that has been
enabled for VP compression.
The FAST VP Time to Compress parameter enables the use of FAST VP

Compression and sets the inactivity threshold for when data becomes
The time to compress can be configured to be between 40 and 400 days,
as well as never. The default is never, meaning FAST VP will not
automatically compress any data.
Prior to enabling FAST VP Compression, users should have an
understanding of their typical business cycle, and the frequency at which
all data may be considered active. For example, end-of-month reporting
or batch processing.
80

As a best practice, the time to compress should initially be set to a
minimum of 40 days. This ensures data needed for any potential end-ofmonth activity during the month the data was created in will not be
compressed prior to the end of that month.
If the typical access cycle for data stretches over a business quarter (three
months), it would then be appropriate to set the time to compress to a
minimum of 100 days.
The FAST Compression Rate is a quality of service setting for the

automated VP compression performed by FAST VP. It affects the
aggressiveness with which data is compressed, after it has been inactive
beyond the time-to-compress value.
The compression rate can be configured to be between 1 and 10, with 1
being the most aggressive.
Setting the compression rate to 1 allows FAST VP to attempt to compress
data as quickly as possible. However, if there is a large amount of data
to be compressed, this may add additional overhead to the back end,
potentially impacting the host I/O response times.
Setting the compression rate to the least aggressive value, 10, causes
FAST VP to greatly reduce the amount of data that will be compressed at
any given time. This setting is less likely to impact the host response
time, but it will take longer for the compression to complete.
The default value for the compression rate is 5. However, the bestpractice recommendation for the initial deployment of FAST VP is to
start with a more conservative value, perhaps 7 or 8.
At a later date, when the level of impact compression has on the array
has been observed, the compression rate can potentially be increased to a
more aggressive setting.
Compression-enabled tiers
In order for data to be automatically compressed it must be allocated in a

thin pool that has been enabled for compression. Compression can be
enabled on any pool, or any location (internal or external), and any
technology type (EFD, FC, SATA).
Typically, any data that has been inactive for a period of time longer
81
than the time to compress will have already been demoted to the lowest
tier in the policy. As such, the recommendation for FAST VP
Compression is that only the lowest tier configured for the Symmetrix
VMAX array, internal or external, should be enabled for compression.
Migration to a FAST VP environment
Migrating from a non-tiered environment to a tiered environment can
provide several challenges. Considerations must be made regarding
both capacity and performance.
From a capacity perspective, not all the data on the single-tiered storage
array may fit into any one tier on the multi-tiered array, so migrations
must be planned very carefully.
When performing a migration to thin devices, it is possible that the thin
devices may become fully allocated as a result of the migration. Because
of this, the target thin devices being migrated to should be configured in
such a way that 100 percent of the space required to complete the
migration is available.
Note: The possibility of a migration fully allocating the target thin devices
can be mitigated by employing existing zero-space reclamation tools. For
more information refer to Zero space reclamation on page 85.
From a performance perspective, there are two different aspects to be

considered. The first is the performance of the data on the target array
when the migration has completed. The second aspect is the
performance of the migration itself.
Any migration into a multi-tiered environment should consider whether
the target tier can provide a sufficient level of performance to the
applications migrated until such time that FAST VP can appropriately
redistribute the data across multiple tiers. Similarly, the target tiers
should be able to absorb a large amount of writes at a performance level
that allows the migration to complete in an acceptable timeframe.
82

Migration planning
When migrating into a multi-tiered FAST VP environment, there are
three primary migration methods available, each of which has options to
ensure the necessary space is available to the target thin devices. The
three methods are:
Migration to a single tier
Migration to multiple tiers
Migration to a FAST VP policy
The following sections discuss the options available to ensure sufficient

space is available to complete the migration successfully for each
migration method.
Migration to a single tier
When migrating to a thin device, the device can only be bound to a

single pool. Typically, all thin devices being used for a single application
are bound to the same pool. In this scenario, the target pool needs to
have sufficient space to allow each of the thin devices to be fully
allocated in order to guarantee the migration will be completed
successfully.
If the target pool has less free space than is needed, the pool reserve
capacity (PRC) can be increased prior to the migration in order to make
the space available. Increasing the PRC makes less space available in the
pool for use by FAST VP. As a result, if the PRC of a pool is increased to
a level greater than the percent of free space in the pool, FAST VP
actively starts moving data out of the pool in order to bring the percent
of free space in line with the new PRC value.
For example, if a pool is 200 TB in size and has a PRC of 10 percent
defined, 180 TB is available for use by FAST VP. Increasing the PRC to 20
percent means that only 160 TB is available to FAST VP. If the pool was
170 TB allocated to devices managed by FAST VP prior to the increase in
PRC, FAST VP would attempt to relocate 10 TB worth of data to decrease
the allocation level to 160 TB.
Prior to starting a migration, the PRC should be changed to a level that
reserves the required capacity in the pool the target devices are bound to.
When migrating to a single tier, the target devices should not be
associated with a FAST VP policy until after the migration has
83
completed.
Note: Depending on the amount of data to be moved, and the existing level
of activity on the array, it may take a significant amount of time to move data
from the pool to reach the new PRC level. As such, any decision to increase
the PRC for the purposes of a migration should be made well in advance of
the migration being executed.
Migration to multiple tiers
If there is insufficient space in a single pool to accept all the data to be

migrated, it may be necessary to involve multiple thin pools on the
target array.
Migration to multiple tiers implies that the target thin devices are not all
bound to a single pool. Rather, multiple target pools are used to
complete the migration.
Individual target devices should be bound to the most appropriate pool
to complete the migration of each device.
The appropriateness of the pool used can be based on the amount of free
capacity of the pool, but also on the performance requirements of the
devices being migrated. For example, the most active devices can be
migrated to a pool, or pools, in the FC tier, while the remaining, less
active devices are bound to a pool, or pools, in the SATA tier.
Ideally, performance data for the devices being migrated is available
prior to the planning of the migration. If this information is not available,
a determination should be made as to which are the most performancesensitive devices being migrated.
Care should be exercised when migrating a large amount of data to the
SATA tier. If the tier is configured with RAID 6 protection, the migration
activity will generate a higher level of write activity to the disk drives.
This could impact both the performance of the migration as well as the
overall performance of the target storage array.
84

When migrating to multiple tiers, the target devices should not be
associated with a FAST VP policy until the migration has completed.
Migration to a FAST VP policy
If there is insufficient space in a single target pool to accept all the

migration data, the VP Allocation by FAST VP Policy feature may be
used to aid the migration. Using allocation by policy, the target thin
devices can all be bound to a single pool. Prior to starting the migration,
the target devices should also be associated with a FAST VP policy.
With the allocation by policy feature enabled, if the pool to which the
target devices are bound fills up during the migration, allocations spills
over to other pools in the FAST VP policy. As long as there is sufficient
space in the pools within the FAST VP policy, all the data will be
migrated successfully.
As with a migration to multiple tiers, care should be taken when
migrating a large amount of data to drives configured with RAID 6
protection.
FAST VP also cannot take the performance requirements of the data
being migrated into account, since no performance history is available.
This means that highly active data may end up being placed on a lowerperforming tier while inactive data may be placed on a higherperforming tier. For some period of time after the migration, the
migrated data may suffer from degraded performance until such time
that FAST VP has the opportunity to optimize the layout of the data for
the actual workload.
When using the migration to a FAST VP policy strategy, the target
devices should be associated with a policy prior to the migration
starting.
Zero space reclamation
Because of the potential for a migration to fully allocate the target thin
device, Virtual Provisioning zero space reclamation should be used
following the migration to deallocate zero data copied during the
migration. It is recommended to pin thin devices managed by FAST VP
prior to starting a zero-space-reclamation task on them.
If either SRDF or Open Replicator is being used, the zero-detection
capability of each should be used during the migration. This can prevent
85
target thin devices from being fully allocated during the migration itself.
Upgrade planning
When planning a drive upgrade in a multi-tier, FAST VP environment,
the biggest question is to which tier capacity should be added. In trying
to determine that, an understanding is required of the increase in overall
workload for the storage array that will come as a result of the added
capacity.
If it is anticipated that not much additional workload will be generated,
and the existing configuration is providing satisfactory performance, it
may be appropriate to simply add more capacity to the SATA tier.
Note: Adding capacity to only one tier will change the relative percentage of
data that can live on the other tiers, which may cause some of the current
workloads to be migrated to new (perhaps lower) tiers in the future.
If a large increase in workload is anticipated, however, the overall

performance of the array and the performance of each storage tier need
to be considered before deciding where capacity should be added.
The following sections describe some key performance indicators (KPIs)
available in Performance Analyzer that can be viewed, along with some
general considerations, to help determine how a drive upgrade should
be planned.
System
From the system level, the overall activity level of the array should be
examined, including the total number of I/Os being performed, as well
as the read/write workload mix. Performance metrics should also be
examined to differentiate between the front-end workload and the backend workload.
Performance metrics that should be looked at in Performance Analyzer
include:
86
Host IOs/sec
% Reads
% Writes
Host MBs/sec
BE IOs/sec
BE Reads/sec
BE Writes/sec
% Cache write pending
Systems with a high number of writes, or high percentage of writes,

should consider adding drives to the higher-performing tiers, EFD and
FC. If FC is configured as RAID 1, this may be the most appropriate tier
to expand.
Note: Systems with a high write-pending level are likely to need additional
cache installed as a part of supporting any significant increase in the usable
capacity of the array.
Virtual Pool tiers

The workload and behavior of each individual tier should also be
examined, primarily at the back end. Metrics that should be looked at in
Performance Analyzer include:
BE Reqs/sec
BE % Reads
BE % Writes
BE Avg Response Time
Total Pool Capacity (GB)
Used Pool Capacity (GB)

Note: If a tier contains multiple pools, these metrics should be examined for
each individual pool in the tier.
Tiers with higher response times, or a higher used-capacity percentage,

are most likely to benefit from being expanded. Expanding a higher tier
may reduce the workload on a lower tier as more active data is promoted
upwards.
Back-end directors
One of the best-practice recommendations for FAST VP is to have a
87
balanced configuration on the back end of the VMAX storage array. As a

result, the workload on each back-end director (DA) should be examined
to determine if a similar workload is being seen on each DA. If not, the
upgrade plan should include drives to achieve a better balance.
The relevant performance metrics for the DAs include:
IOs/sec
% Reads
% Writes
% Busy
Ideally, each logical DA should have a similar workload profile for each
of these metrics. Should any imbalance exist, the drive upgrade should
include the correct mix of drives to achieve balance on the DAs.
88
Conclusion
Conclusion
EMC Symmetrix VMAX FAST VP for Virtual Provisioning environments
automates the identification of active or inactive application data for the
purposes of reallocating that data across different performance/capacity
tiers within an array. FAST VP proactively monitors workloads at both
the LUN and sub-LUN level in order to identify busy data that would
benefit from being moved to higher-performing drives. FAST VP also
identifies less-busy data that could be moved to higher-capacity drives,
without existing performance being affected. This promotion/demotion
activity is based on policies that associate a storage group to multiple
drive technologies, or RAID protection schemes, by way of thin storage
pools, as well as the performance requirements of the application
contained within the storage group. Data movement executed during
this activity is performed non-disruptively, without affecting business
continuity and data availability.
89
Appendix A: FAST VP state

There are five possible states that the FAST controller can be reported in.
These are:
Enabled: All FAST VP functions are performed. Performance data

collection, performance data analysis, data-movement request
generation, and data-movement execution.
Disabled: Only performance data collection is performed. Data

analysis is not performed, and data movement is not executed.
Disabling: The transition of the FAST controller from Enabled to

Disabled.
DisabledwithError: The FAST controller has stopped operation due

to an internal error. Statistics collection and FAST VP performance
data movements continue to be performed, however, FAST VP
compliance movements are not performed.
Degraded: FAST VP can perform some or all of its functions.

However, it cannot perform each function fully.
Enabled state
When the state of the FAST controller is queried, and the state is
Enabled, the current activity being performed by the controller is also
displayed. Valid activities include:
Idle: The FAST controller is currently idle.
RunningPlan: There are currently active data-movement tasks

running, moving thin device data between tiers.
Degraded state
When the state of the FAST controller is Degraded, a reason code is
displayed when the FAST state is queried, and it indicates the cause of
the degraded state.
These reason codes include:
90
Invalid Swap/Performance time windows: At least one of the

defined time windows is invalid. To correct, each time window

should be checked, and any invalid time windows should be deleted
or modified.
Invalid device attributes: One or more storage groups have an

invalid priority in a FAST policy. To correct, each storage groups
priority should be checked in the FAST policy they are associated
with. Any invalid priority should be modified to a valid value.
Invalid FAST parameters: One or more of the FAST controller

configuration settings are invalid. To correct, each configuration
setting should be checked and set to a valid value.
Performance time window is not present or does not extend into the
future: No performance time window, default or user-defined, exists,
or any that do exist have expired. To correct, a valid, inclusion
performance time window should be created.
FAST thin move time window is not present or does not extend into
the future: No thin data movement time window, default or userdefined, exists, or any that do exist have expired. To correct, a valid,
inclusion thin data movement time window should be created.
FAST VP compliance movement failed: The most recent attempt to

perform a FAST VP compliance movement was not successful. EMC
customer service should be contacted to investigate the reason for
the failure. If a subsequent attempt to perform a compliance
movement is successful, the degraded state is cleared.
FAST VP performance movement policy update failed: The most

recent attempt to generate a data-movement policy failed. EMC
customer service should be contacted to investigate. If a subsequent
attempt to generate a movement policy is successful, the degraded
state is cleared.
FAST VP is not licensed: An entitlement file including FAST VP has

not been loaded to the Symmetrix array. To correct, the appropriate
entitlement file should be obtained from EMC and loaded to the
Symmetrix array.
Statistics collection is failing for thin devices - No Performance

movement will happen: Performance statistics are not being
collected for thin devices under FAST VP control. EMC Customer
Service should be contacted to investigate. If a subsequent attempt to
collect statistics is successful, the degraded state is cleared.
Timed out attempting to communicate with the FAST controller:

Either the FAST controller running on the service processor is
unavailable, or the service processor itself is unavailable. EMC
Customer Service should be contacted to investigate.
91
Appendix B: Feature support

The following table describes the minimum Enginuity and management
interface levels needed to support various FAST VP features.
Feature
Enginuity
Management interface
FAST VP (Base)
5875.135.91
Solutions Enabler V7.3

SMC 7.3
Unisphere for VMAX 1.0
Setting PRC per pool
5875.198.38
Solutions Enabler V7.3.1

SMC 7.3.1
VP Allocation by FAST
Policy
5876.82.57
FAST VP SRDF
coordination
5876.82.57
FAST VP SRDF
coordination for multi-site
SRDF
5876.229.145
External tier (FTS)
5876.82.57

Storage group reassociation
5876.82.57

FAST VP for CKD
5876.82.57
Solutions Enabler V 7.4

92

FAST VP for IBM i
5876.82.57

FAST VP Compression
5876.159.102

Four tiers in a FAST VP

policy
5876.159.102
User-defined FTS tier
5876.159.102

93
Appendix C: Best practices quick reference

The following provides a quick reference to the general best-practice recommendations
for planning the implementation of a FAST VP environment.
The best practices documented are based on features available in Enginuity 5876.229.145,
Solutions Enabler V7.6, and Unisphere for VMAX 1.6.
Note: For more details on these recommendations, and other considerations,
see Best practice considerations on page 56.
FAST VP configuration parameters

FAST VP includes multiple configuration parameters that control its behavior. This
appendix provides a brief summary of each of the best-practice recommendations. For
more details on each recommendation, click on a heading to redirect to the appropriate
section of the document.
Use the default performance time window to collect performance metrics 24 hours a day,
every day.
Create a data movement window to allow data movement for the same period of time
that the performance time windows allow data collection.
Workload Analysis Period (WAP)
The best-practice recommendation for the Workload Analysis Period is to match it to the
performance time window to cover one calendar week.
Initial Analysis Period (IAP)
At the initial deployment of FAST VP, set the Initial Analysis Period to 168 hours to
ensure that a typical weekly workload cycle is seen. After this period has passed, the
value can be dropped to 24 hours.
94

FAST VP Relocation Rate (FRR)
For the initial deployment of FAST VP, start with a conservative value for the relocation
rate, perhaps 7 or 8. At a later date, the FRR can be gradually lowered to a more
aggressive level.
Pool Reserved Capacity (PRC)
For individual pools with bound thin devices, set the PRC based on the lowest allocation
warning level for that thin pool. For pools with no bound thin devices, set the PRC to 1
percent.
VP Allocation by FAST Policy should be enabled.

The FAST VP Time to Compress should initially be set to a minimum of 40 days to

account for a typical monthly workload cycle, or 100 days to account for a three-month
cycle.
For the initial deployment of FAST VP, start with a more conservative value for the
compression rate, perhaps 7 or 8. At a later date, the compression rate can potentially be
increased to a more aggressive setting.
FAST VP Compression
For FAST VP Compression, it is recommended that only the lowest tier configured for
the Symmetrix VMAX array, internal or external, be enabled for compression.
FAST VP policy configuration
The ideal FAST VP policy would be 100 percent EFD, 100 percent FC, and 100 percent
SATA. While ideal, operationally it may not be appropriate to deploy the 100/100/100
policy. There may be reasons to limit access to a particular tier within the array.
The best way to determine the appropriate policies for a FAST VP implementation is to examine
the workload skew for the application data to be managed by FAST VP. This can be done by
using a tool such as Tier Advisor.
Thin device binding
The best-practice recommendation is to bind all thin devices to a pool within the FC tier.
VP allocation by FAST policy should be enabled.
It is not recommended to bind thin devices, under FAST VP control, to the EFD tier.
95
A best-practice recommendation is to not pre-allocate thin devices managed by FAST VP.

RAID protection considerations
For EFD, choose RAID 5 (3+1) protection.

For FC, choose RAID 1 protection.
For SATA, choose RAID 6 (6+2) protection.
Drive configuration
Where possible, balance physical drives evenly across DAs. Configure more, smaller
EFDs, rather than fewer, larger EFDs, to spread the I/O load as wide as possible.
Storage group priority
The best-practice recommendation is to use the default priority of 2 for all storage groups
associated with FAST VP policies.
SRDF
As a general best practice, FAST VP should be employed for both R1 and R2 devices,
particularly if the remote R2 array has also been configured with tiered storage capacity.
Similar FAST VP tiers and policies should be configured at each site.
FAST VP SRDF coordination should be enabled for storage groups containing SRDF R1
devices.
96
References
References
EMC Solutions Enabler Symmetrix Array Controls CLI Product

Guide
EMC Solutions Enabler Symmetrix Array Management CLI Product

Guide
EMC Solutions Enabler Symmetrix CLI Command Reference HTML

Help
EMC Solutions Enabler Installation Guide
EMC Symmetrix VMAX Series Product Guide
Implementing Fully Automated Storage Tiering for Virtual Pools (FAST

VP) for EMC VMAX Series Arrays
Best Practices for Fast, Simple Capacity Allocation with EMC

Symmetrix Virtual Provisioning Technical Note
z/OS and Virtual Provisioning Best Practices
Design and Implementation Best Practices for EMC Symmetrix

Federated Tiered Storage (FTS) Technical Note
Best Practices for Nondisruptive Tiering via EMC Symmetrix Virtual

LUN Technical Note
Copyright 2013 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.
97

Docu31003 - FAST VP For Symmetrix VMAX Theory and Best Practices For Planning and Performance PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Docu31003 - FAST VP For Symmetrix VMAX Theory and Best Practices For Planning and Performance PDF

Caricato da

Copyright:

Formati disponibili

FAST VP for EMC Symmetrix VMAX

Theory and Best Practices

This technical note contains information on these topics:

Executive summary ................................................................................... 2

Fully Automated Storage Tiering

Fully Automated Storage Tiering

Improving application performance at the same cost, or providing

Elimination of manually tiering applications when workload

Automating the process of identifying data that can benefit from

Optimizing and prioritizing business applications, allowing

Delivering greater flexibility in meeting different price/performance

The need for FAST

Fully Automated Storage Tiering

Symmetrix VMAX Family arrays. The primary differences are:

Cost per unit of storage capacity

Cost per unit of storage request processing

This disparity in suitable workloads presents both an opportunity and a

Fully Automated Storage Tiering

FAST DP and FAST VP

FAST DP operates on disk group provisioning Symmetrix volumes. Data

Fully Automated Storage Tiering

can operate simultaneously within a single array. Aside from some

FAST managed objects

Storage tier: A shared resource with common drive technologies and

Storage group: A logical grouping of devices for common

Figure 1 shows the FAST managed objects.

Figure 1. FAST managed objects

Virtual Provisioning tiers

A thin pool may only belong to one VP tier. Overlapping of pools

belong to one storage group that is under FAST control.

IBM i (520-byte block emulation), ICOS, ICL

FTS-encapsulated thin devices

A Symmetrix VMAX storage array supports up to 8,192 storage groups.

FAST policy association

FAST policy configuration

Figure 2. FAST policy association

In the case of the Custom policy, 10 percent of the configured capacity of

FAST policy compliance

A special case of noncompliance is when some of the data in the storage

Figure 3. FAST VP components

controller should collect performance data. Analysis is then performed to

FAST VP has two modes of operation, Automatic or Off. When operating

Enabled: All FAST VP functions are performed (performance data

Disabled: Only performance data collection is performed. Data

Disabling: The FAST controller is transitioning from Enabled to

DisabledwithError: The FAST controller has stopped operation due

Degraded: FAST VP can perform some or all of its functions.

FAST VP time windows

Performance time window

Data movement time window

The performance time windows are used to specify when performance

and managing time windows. The enhanced method uses a time

Legacy time window characteristics

For enhanced time windows, the default behavior is also to collect

FAST VP Data Movement Mode

Workload Analysis Period

Initial Analysis Period

Pool Reserved Capacity (PRC)

FAST VP Relocation Rate (FRR)

VP Allocation by FAST Policy

FAST VP Time to Compress

FAST VP Compression Rate

Initial Analysis Period