This article provides the brief FAST operation theory overview and common FAST VP configuration SYMCLI with step by step command example.

FAST operation theory and architecture.

Fully Automated Storage Tiering (FAST) is the VMAX technology that automates the identification of active and inactive data for the purposes of relocating application data across different performance/capacity tiers within an array.  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.

FAST VP automates the identification of thin device extents for the purpose 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 higher-performing drives (EFD). 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 Tier: A share resource with common drive theologies and RAID protection
• FAST Policies: A set of tier usage rules that provide guidelines for data placement and movement across tiers to achieve service levels for one or more storage groups.
• Storage Group: A logical grouping of devices for common management.

There are two components of FAST VP, Enginuity and FAST controller. Enginuity is the storage operating environment that controls components within the array. The FAST controller is a service that runs on the service processor.

When FAST VP is active, both components participate in the execution of two algorithms (the intelligent-tiering algorithm and the allocation-compliance 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 data-movement 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.

A Performance time windows can be defined to specify when the FAST VP 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 ca 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.

FAST VP Operation Mode and common SYMCLI

FAST VP has two modes of operations, Automatic or Off. When operating in the Automatic mode, data analysis and data movement occur continuously during the defined data movement windows. In the Off mode, performance statistics continue to be collected, but no data analysis or data movement take place. Following are few common FAST VP SYMCLIs:

• symfast
• symtier
• symsg

For example:

To create a storage group named VP_ProdApp1 in array SID ending with 1849:

symsg –sid 1849 create VP_ProdApp1

Adding devices 100 to 104 into storage group:

symsg –sid 1849 -sg VP_ProdApp1 addall devs –range 100:104

Create a thin pool for raid 5 EDF device:

symtier –sid 1849 create –name RAID5_EFD_Tier –tgt_raid5 –tgt_prot 7+1 –technology EFD –vp –pool R5_EFD_Pool

Create a FAST Policy named Platinum:

symfast -sid 1849 -fp create -name Platinum

Adding Tier into Policy and set max usage percentage is 25%:

symfast -sid 1849 -fp -fp_name Platinum add -tier_name RAID5_EFD_Tier -max_sg_percent 25

Associate Storage Group with FAST policy:

symfast -sid 1849 -fp_name Platinum associate -sg VP_ProdApp1 -priority 2

Enginuity microcode upgrades FAST performance impact

In general, if the data is not in migrating state. Enginuity upgrade is not going to have any performance impact of FAST VP. As the best practice of upgrading Enginuity, the engineer will suspend the FAST VP first before performs the Enginuity upgrade. Then resume it after the upgrade is completed. If FAST VP is in “Executing Thin Change” (Below figure), we have to wait till it completed (It need 24-48 depend on the size of data). Otherwise, the upgrade process will cause losing all previous performance statistics. In result, the system could not determine whether the data is hot or cold. It need spend a lot of time to collecting the performance statistics again. This process will certainly have negative impact of overall array performance.

Author: Fenglin Li

iEMC APJ

Please click here for for all contents shared by us.