Storage System Best Practices 
Performance     
61
MetaA: Oracle1
R 10 MetaLUNs
1.1 TB
4 x 8-disk RAID 1/0
1.1 TB Useable
MetaB: Oracle 2
MetaC: TEMP, RBS
63 GB   * 4 LUNS
113 GB * 4 LUNS
70 GB   * 4 LUNS
50 GB   * 4 LUNS
MetaD: Staging
4 x 5-disk RAID 5
1.1 TB Useable
Base LUN Size
MetaE: NFS Share 1
R 5 MetaLUNs
1.1 TB
MetaF: NFS Share 2
MetaG: Oracle Archive
50 GB   * 4 LUNS
125 GB * 4 LUNS
50 GB   * 4 LUNS
50 GB   * 4 LUNS
MetaH: Dumps
Base LUN Size
These 4 
LUNS 
make 1 
meta 
(D)
A RAID group with 4 component LUNs
Logs 1
Logs 2
RAID 1 pairs exposed as 
normal LUNs
Figure 5  Example of data fencing with RAID group sets and metaLUNs 
In the example shown in Figure 5, access to the NFS share metaLUNs will not interfere with the Oracle 
servers‘ access to their data tables or to their logs.
MetaLUN expansion 
The next step is to set up the strategy for expansion. The goals for expansion are: 
Maintain distribution of data across many drives. 
Use capacity efficiently. 
The approach to achieve these goals is: 
When capacity is anticipated for a metaLUN, add drives to existing RAID groups in the set. 
Bind expansion LUNs on the RAID groups of the metaLUN‘s set.
Add expansion LUNs to metaLUNs as a new striped component. 
MetaLUN base LUN stacking or base LUN rotation 
When creating more than one metaLUN from a set of RAID groups, rotate the RAID group of the base LUN 
for each metaLUN.  Rotation puts the base LUN of each metaLUN on a different RAID group of the RAID 
groups making up the metaLUN.  Doing this evenly spreads the I/O load across all the metaLUN‘s RAID 
groups. An example is if there are four metaLUNs A through D created on LUNs using four RAID groups 
labeled RAID Group 1, RAID Group 2, RAID Group 3, and RAID Group 4.  Define the base LUN of the 
first metaLUN (Meta A) to be on RAID Group 1.  Define the base LUN of the second metaLUN (Meta B) 
to be on RAID Group 2.  Define the base LUN of Meta C to be on RAID Group 3.  Define the base LUN of 
MetaLUN D to be on RAID Group 4.  In Figure 6 the example is illustrated.  Each color stripe denotes a 
different metaLUN; the base LUN for each meta is on a different RAID group. 
Pdf conversion to powerpoint - Library software class:C# Create PDF from PowerPoint Library to convert pptx, ppt to PDF in C#.net, ASP.NET MVC, WinForms, WPF
Online C# Tutorial for Creating PDF from Microsoft PowerPoint Presentation
www.rasteredge.com
Pdf conversion to powerpoint - Library software class:VB.NET Create PDF from PowerPoint Library to convert pptx, ppt to PDF in vb.net, ASP.NET MVC, WinForms, WPF
VB.NET Tutorial for Export PDF file from Microsoft Office PowerPoint
www.rasteredge.com
Storage System Best Practices 
62
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
RAIDGroup1 RAIDGroup2
RAIDGroup3
Meta A
Meta B
Meta C
Meta D
MetaLUN 
Base LUN
RAIDGroup4
RAIDGroup1 RAIDGroup2
RAIDGroup3
Meta A
Meta B
Meta C
Meta D
MetaLUN 
Base LUN
RAIDGroup4
Figure 6  
MetaLUN base LUN stacking 
The opposite of LUN rotation in metaLUNs is called LUN vertical striping.  Vertical striping puts all the 
base LUNs on the same RAID group.  Avoid vertical striping of LUNs within a metaLUN.  Vertical striping 
puts all of the LUNs metadata on the same RAID group.  Frequently, this will cause a single drive of the 
RAID group to have very high utilization.  In addition large I/Os or sequential I/Os may send requests to 
several, widely-separated areas of a vertically striped RAID group.  This results in high drive seeks for 
every request, which increases the response time for all the LUNs on the RAID group. 
Further information 
Further information on metaLUNs is available in the EMC CLARiiON MetaLUNs white paper.  This paper 
is available on Powerlink. 
LUN shrink 
Conventional LUNs, metaLUNs, and pool-based LUNs (thick and thin) may have their capacity reduced to 
reclaim unused storage capacity.  This process is called LUN shrink.  LUN shrink is a FLARE revision-
dependent feature.  It is available on FLARE revision 29.0 and later for traditional LUNs. Pool LUN shrink 
is a feature found in FLARE revision 30.0 and later.   LUN shrink is only supported by hosts with the 
Microsoft Server 2008 operating system and later.   
LUN shrinking is a two-step process consisting of a host-volume shrink followed by a LUN-volume shrink.  
Host-volume shrink is performed from the MS Server host though its Disk Administration function.  LUN 
volume shrink is directed by the user on the host, and executed on the CLARiiON.  Both steps may be 
performed while a workload is present.  The LUN volume shrink step requires that the ―DISKRAID.EXE‖ 
application be installed on the host.  It is performed automatically, after the first step. A LUN shrink 
requires several seconds (less than a minute) to perform. 
A host file system defragmentation should be performed before a LUN shrink to consoli
date the LUN‘s 
capacity. This yields the largest amount the LUN can be shrunk. 
Shrinking a LU
N may leave the LUN‘s underlying RAID group in a fragmented state.  You may need to 
perform a RAID group defragmentation to achieve the maximum RAID group capacity that is provided by a 
LUN shrink. 
FLARE revisions 30.0 and earlier do not support RAID 6 group defragmentation.  This means that you may 
not be able to utilize the aggregated capacity on a RAID 6 group after shrinking RAID 6 LUNs.  See the 
RAID groups
‖ section for the recommendation of defragmenting RAID 6 groups.
Virtual Provisioning: thin and thick LUNs  
Virtual Provisioning provides for the provisioning of thin and thick provisioning of LUNs.  Virtual 
Provisioning is a licensable feature and requires FLARE revision 28.0 or later. 
Storage pools can support both thin and thick LUNs.  Thin LUNs present more storage to an application 
than is physically available.  Relative to thin LUNs, thick LUNs provide guaranteed allocation for LUNs 
Library software class:Online Convert PowerPoint to PDF file. Best free online export
area. Then just wait until the conversion from Powerpoint to PDF is complete and download the file. The perfect conversion tool.
www.rasteredge.com
Library software class:C# powerpoint - PowerPoint Conversion & Rendering in C#.NET
And detailed C# demo codes for these conversions are offered below. C# Demo Codes for PowerPoint Conversions. PowerPoint to PDF Conversion.
www.rasteredge.com
Storage System Best Practices 
Performance     
63
within a storage pool, as well as more deterministic performance.   Note that thick LUNs require FLARE 
version 30.0 or later.  The presentation of storage not physically available avoids over-provisioning the 
storage system and under-utilizing its capacity.  Thin LUNs incrementally add to their in-use capacity.  
When a thin LUN requires additional physical storage, capacity is non-disruptively and automatically added 
from a storage pool.  Thick LUNs reserve their full in-use capacity from the pool when they are created.  
Thin and thick LUNs may be provisioned within the same pool.   
When creating storage pools: 
If the goal is the most efficient use of capacity - provision the pool with thin LUNs.   
If the goal is the highest pool-based performance - provision the pool using thick LUNs.  
In addition, the storage pool‘s capacity can be non
-disruptively and incrementally added to with no effect on 
the pool‘s LUNs.  
You can provision pool LUNs using Unisphere or the CLI. 
Once created, pool provisioned LUNs are largely automatic in their upkeep.  This simplifies and reduces the 
administrative actions required in maintaining the storage system.  An initial investment in planning to 
correctly provision the storage pool will result in the best on-going pool LUN performance, capacity 
utilization and availability. 
Conceptually, the storage pool is a file system overlaid onto a traditional RAID group of drives.  This file 
system adds overhead to performance and capacity utilization for thin and thick LUNs.  Thick LUNs have 
less of a performance overhead than thin LUNs due to the granularity of space allocation and mapping 
between virtual and physical layers.   
In addition, availability should be considered when implementing pools.  A pool with a large number of 
drives will be segmented into multiple private RAID groups.  Data from many LUNs will be distributed 
over one or more of the pool‘s RAID groups.  The availability of the pool includes the availability of 
all the 
pool‘s RAID groups considered as one.  (Availabil
ity is at the single RAID group level with traditional 
LUNs.)  Workloads requiring the highest level of performance, availability, and capacity utilization should 
continue to use traditional FLARE LUNs. As with traditional LUNs, storage pool drive count and capacity 
need to be balanced with expected LUN count and workload requirements.  To get started quickly, begin 
with the recommended initial pool size, expand in the recommended increments, and don‘t greatly exceed 
the recommended maximum pool size found in the 
Quick Guidelines
section below. 
An in-depth discussion of Virtual Provisioning can be found in the EMC CLARiiON Virtual Provisioning 
white paper, available on Powerlink. 
Creating storage pools 
For the most deterministic performance create few homogeneous storage pools with a large number of 
storage devices.  A homogeneous pool has the same type, speed, and size drives in its initial allocation of 
drives.  Heterogeneous pools have more than one type of drive.  See the ―
Fully Automated Storage Tiering 
(FAST) Virtual Provisioning
‖ section for heterogeneous pool management.
A single RAID level applies to all the pool‘s private RAID groups.  Pools may be created to be of RAID 
types 5, 6, or 1/0.  Use the general recommendations for RAID group provisioning of FLARE LUNs when 
selecting the provisioning of the storage pool‘s RAID types.  
When provisioning a pool with SATA drives with capacities of 1 TB or larger, we strongly recommend 
RAID level 6. All other drive types can use either RAID level 5 or 1/0. 
Library software class:.NET PDF Document Viewing, Annotation, Conversion & Processing
XDoc.PDF SDK for .NET. RasterEdge XDoc.PDF for .NET is a professional .NET PDF solution that provides complete and advanced PDF document processing features.
www.rasteredge.com
Library software class:C# powerpoint - Convert PowerPoint to TIFF in C#.NET
Supported. Load, Save Document. Preview Document. Conversion. Convert PowerPoint to PDF. Convert PowerPoint to HTML5. Convert PowerPoint to
www.rasteredge.com
Storage System Best Practices 
64
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
Expanding pools 
You may not be able to create a large pool in a single step.  In addition, you may not be able to add a large 
number of drives at the same time.  This restriction allows a pool to initialize and become fully functional 
on-demand.   
The maximum number of drives that you can add to a pool at one time or use to create a pool  is model-
dependent, and is listed in Table 15.  This number is lower than the maximum number of pool drives per 
model.   
Table 15  Pool drive increments for different CLARiiON models  
Maximum pool 
drive incremental  
increases 
CX4-120 
40 
CX4-240 
80 
CX4-480 
120 
CX4-960 
180 
To create a pool with a greater number of drives than the maximum pool drive increment, create the pool 
and then add increments of drives until the pool has the desired number of drives.  (The pool can be 
expanded again after a delay of one or two minutes.)  The amount of time between increments depends on 
the storage system model, the drives added, and number of drives.   
For example, the maximum number of drives that can be added to a CX4-960 pool is 180.  To create a 480 
Fibre Channel drive pool, you should do it in three equal provisioning steps.  First, create an initial pool 
with 160 drives. Note this will create a pool of 32 (4+1) RAID groups, in a RAID 5 configured pool.  
Second, expand it with an increment of 160 drives. A third and final expansion of 160 drives would bring 
the pool to 480 drives. 
Number of storage pools 
The number of storage pools per storage system is model-dependent.  
Table 16 shows the maximum number per CLARiiON model.   
Library software class:How to C#: Overview of Using XDoc.PowerPoint
XDoc.PowerPoint for .NET, like PPTXDocument and PPTXPage. PowerPoint Conversion. XDoc.PowerPoint SDK for .NET empowers C# developers
www.rasteredge.com
Library software class:C# powerpoint - Convert PowerPoint to PDF in C#.NET
PowerPoint to PDF Conversion Overview. RasterEdge XDoc.PowerPoint empowers your C#.NET application with advanced PowerPoint to PDF conversion functionality.
www.rasteredge.com
Storage System Best Practices 
Performance     
65
Table 16 Thin provisioning storage pools per storage system 
CLARiiON 
model 
Maximum 
thin storage pools  
per storage system 
CX4-120 
20 
CX4-240 
40 
CX4-480 
40 
CX4-960 
60 
Storage pool size 
The maximum number of drives in a storage pool is storage system model-dependent.  Generally, EMC 
recommends that you configure storage system pools as RAID 5.  This results in the highest percentage of 
usable pool capacity with the fewest number of drives.   
Table 17 Virtual Provisioning storage pool storage device configurations, FLARE 30.0 
CLARiiON 
model 
Minimum  
RAID 5 pool 
size 
(drives) 
Maximum  
pool size 
(drives) 
Maximum total 
drives in all pools 
(drives) 
CX4-120 
3  
115 
115 
CX4-240 
3  
235 
235 
CX4-480 
3  
475 
475 
CX4-960 
3  
955 
955 
EMC recommendations for creating homogeneous pools are as follows:  
We recommend Fibre Channel hard drives for Virtual Provisioning pools with thin LUNs due to their 
overall higher performance and availability. 
Create pools using storage devices that are the same type, speed, and size for the most predictable 
performance.  It may be advisable to keep Fibre Channel and SATA hard drives in separate pools to 
service different workloads with varying performance and storage utilization needs. 
Usually, it is better to use the RAID 5 level for pools.  It provides the highest user data capacity per 
number of pool storage devices and proven levels of availability across all drive types.  Use RAID 6 if 
the pool is composed of SATA drives and will eventually exceed a total of 80 drives.  Use RAID 6 if the 
pool is made up of any number of large capacity (  1 TB) SATA drives. 
Initially, provision the pool with the largest number of hard drives as is practical within the storage 
system‘s maximum limit.  For RAID 5 pools the initial drive allocation should be at least five drives and 
a quantity evenly divisible by five.  RAID 6 pool initial allocations should be evenly divisible by eight.  
RAID 1/0 pool initial allocations should be evenly divisible by eight. 
If you specify 15 drives for a RAID 5 pool - Virtual Provisioning creates three 5-drive (4+1) RAID 
groups. This is optimal provisioning.  
If you specify 18 drives for a RAID 5 pool 
Virtual Provisioning creates three 5-drive (4+1) RAID 
Library software class:VB.NET PDF Converter Library SDK to convert PDF to other file
Conversion of MS Office to PDF. This guide give a series of demo code directly for converting MicroSoft Office Word, Excel and PowerPoint document to PDF file
www.rasteredge.com
Library software class:C# PDF Converter Library SDK to convert PDF to other file formats
C#.NET PDF - PDF Conversion & Rendering SDK for C#.NET. A best C# PDF converter control for adobe PDF document conversion in Visual Studio .NET applications.
www.rasteredge.com
Storage System Best Practices 
66
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
groups and one 3-drive (2+1) RAID group. This provisioning is less optimal.  
If you specify 10 drives for a RAID 6 pool 
Virtual Provisioning creates one 10-drive (8+2) RAID 
group. This is larger than standard, because an additional group cannot be created. It is acceptable, 
because the RAID groups are the same size. 
If you specify 10 drives for a RAID 1/0 pool 
Virtual Provisioning creates one 8-drive (4+4) and 
one 2-drive (1+1) RAID group. This is not optimal, because some pool resources will be serviced 
by a single drive pair. For RAID 1/0 pools, if the number of drives you specify in pool creation or 
expansion isn‘t div
isible by eight, and if the remainder is 2, the recommendation is to add additional 
drives or remove two drives to that disk count to avoid a private RAID group of two drives being 
created.  
In a storage pool, the subscribed capacity is the amount of capacity that has been assigned to thin and 
thick LUNs. When designing your system, make sure that the expected subscribed capacity does not 
exceed the capacity that is provided by maximum number of drives allowed in a storage system‘s pool. 
This ensures that increased capacity utilization of thin LUNs can be catered for by pool expansion as 
necessary.     
Expanding homogeneous storage pools 
A homogeneous pool is a storage pool with drives of a single type.  For best performance expand storage 
pools infrequently
, maintain the original character of the pool‘s storage devices, and make the largest 
practical expansions. 
Following are recommendations for expanding pools: 
Adjust the % Full Threshold parameter (Default is 70%) to the pool size and the rate applications are 
consuming capacity.  A pool with only a few small capacity drives will quickly consume its available 
capacity. For this type of pool you should have lower alerting thresholds.  For larger pools slowly 
consuming capacity you should use higher thresholds.  For example, for the largest pools, a good initial 
% Full Threshold parameter value is 85%.  
Expand the pool using the same type and same speed hard drives used in the original pool.   
Expand the pool in large increments.  For RAID level 5 pools use increments of drives evenly divisible 
by five, not less than five.  RAID 6 pools should be expanded using eight-drive evenly divisible 
increments.  Pools may be expanded with any amount of drives. You should expand the pool with the 
largest practical number of drives.  Pools should not 
be expanded with fewer than a single RAID group‘s 
number of drives.  The performance of the private RAID groups within the pool by a smaller, later 
expansion may be different from the pool‘s original RAID groups. Doubling the s
ize of a pool is the 
optimal expansion.  
Be conservative about the eventual maximum number of hard drives in the pool.  More pools with a 
smaller number of storage devices will have better availability than fewer pools with a greater number of 
storage devices. 
Pool LUNs should not be defragmented.  This includes RAID group defragmentation and host file 
system defragmentation.  RAID group defragmentation is not an option for pool-based LUNs.   
The expansion drives do not need to have the same capacity as the initial allocation of hard drives.  
However, it is recommended that all the drives in the expansion be of the same capacity to maintain a 
Library software class:C# PDF Convert: How to Convert MS PPT to Adobe PDF Document
C# PDF Convert: How to Convert MS PPT to Adobe PDF Document. Provide Free Demo Code for PDF Conversion from Microsoft PowerPoint in C# Program.
www.rasteredge.com
Library software class:VB.NET PowerPoint: Complete PowerPoint Document Conversion in VB.
resolution, bit depth, scaling, etc. Implement Conversion from PowerPoint to PDF in VB.NET, Converting PowerPoint document to PDF
www.rasteredge.com
Storage System Best Practices 
Performance     
67
consistent level of distributed pool capacity utilization balanced with performance. 
Quick guidelines for creating and expanding storage pools 
Table 18 provides recommendations for quickly creating and extending well-balanced RAID 5-based 
storage pools.  Note that workloads vary greatly in their requirements for capacity, performance, and 
availability.  These recommendations may need to be tailored using the information in the preceding 
sections to address individual requirements. 
For example, the minimum RAID 5 pool size is specified as three drives, although five maintains 
performance and capacity utilization, while the recommended value or greater (in numbers evenly divisible 
by five) may offer better performance depending on workloads and distribution of access across pool 
resources. 
Table 18 Recommended storage pool storage device allocations 
CLARiiON  
model 
Recommended  
initial  
RAID 5 pool size 
(drives) 
Recommended  
incremental  
RAID 5 expansion 
(drives) 
Recommended 
maximum  
RAID 5 pool size 
(drives) 
Recommended 
thin storage pools 
per storage system 
(pools) 
CX4-120 
20 
CX4-240 
10 
10 
40 
10 
CX4-480 
20 
20 
60 
30 
CX4-960 
20 
20 
80 
50 
Creating pool LUNs 
The general recommendations toward traditional LUNs apply to pool LUNs.  (See the ―
LUN provisioning
‖ 
section on page 55.) 
The largest capacity pool LUN that can be created is 14 TB. 
The number of thin LUNs created on the storage system subtracts from the storage system‘s total LUN 
hosting budget.  A large number of pool LUNs are creatable per storage pool (Table 20). In the table, the 
column ―Maximum storage system LUNs all types‖ refers to traditional LUNs, metaLUNs, snapshot LUNs, 
and pool LUNs.  The maximum number of LUNs visible to a host is shown separately in the table.  Be 
aware of the number and types of LUNs already created or anticipated for creation.  A few thin pools with a 
lot of thin LUNs can easily account for a substantial part of a storage system‘s maximum host visible LUN 
count.   
Table 19 Thin provisioning thin LUN provisioning recommendations 
CLARiiON 
model 
Maximum 
storage system 
LUNs all types 
Maximum 
host visible 
LUNs 
Maximum 
LUNs 
per storage pool 
CX4-120 
1636 
1024 
512 
CX4-240 
1636 
1024 
1024 
CX4-480 
5220 
4096 
2048 
CX4-960 
6244 
4096 
2048 
Avo
id trespassing pool LUNs.  Changing a pool LUN‘s SP ownership may adversely affect performance.  
After a pool LUN trespass, a pool LUN‘s private information remains under control of the original owning 
SP.  This will cause the trespassed LUN‘s I/Os to cont
inue to be handled by the original owning SP.  This 
Storage System Best Practices 
68
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
results in both SPs being used in handling the I/Os.  Involving both SPs in an I/O increases the time used to 
complete an I/O.  Note that the private RAID groups servicing I/O to trespassed pool LUNs may also be 
servicing I/O to non-trespassed pool LUNs at the same time.   There is the possibility of dual SP access for 
the period some pool LUNs are trespassed. If a host path failure results in some LUNs trespassing in a 
shared pool, the failure should be repaired as soon as possible and the ownership of those trespassed LUNs 
be returned to their default SP. 
Eventually, the CLARiiON‘s ALUA feature will link both the trespassed pool LUNs and their private 
information under the sole control of the new owning SP.  However, response time will be higher until this 
occurs. 
Pools with high bandwidth workloads 
When planning to use a pool LUNs in a high bandwidth workload, the required storage for the LUN should 
be pre-allocated. For FLARE revision 30.0 and later, thick LUNs should be used.  For virtual provisions 
using earlier versions of FLARE a pre-allocation of the storage should be performed.  
Pre-
allocation results in sequential addressing within the pool‘s thin LUN ensuring high bandwidth 
performance.  Pre-allocation can be performed in several ways including migrating from a traditional LUN; 
performing a full format of the file system, performing a file write from within the host file system; or 
creating a single  Oracle table from within the host application.  In addition, only one concurrent pre-
allocation per storage pool should be performed at any one time.  More than one thin LUN per pool being 
concurrently pre-allocated can reduce overall SP performance. 
Capacity overhead 
There is a fixed capacity overhead associated with each LUN created in the pool.  Take into account the 
number of LUNs anticipated to be created, particularly with small allocated capacity pools. 
A pool LUN is composed of both metadata and user data, both of which come from the storage pool.  A 
pool LUN‘s metadata is a capacity overhead that subtracts from the pool‘s user data capacity.   Thin and 
thick LUNs make different demands on available pool capacity when they are created.   Note the User 
Consumed Capacity of a thin LUN is some fraction of the User Capacity of the LUN. 
Any size thin LUN will consume about 3 GB of pool capacity: slightly more than 1 GB of capacity for 
metadata, an initial 1 GB of pool capacity for user data.  An additional 1 GB of pool capacity is prefetched 
before the first GB is consumed in anticipation of more usage.  This totals about 3 GB.  The prefetch of 1 
GB of metadata remains about the same from the smallest though to the largest (>2 TB host-dependent) 
LUNs.  Additional metadata is allocated from the first 1 GB 
of user data as the LUN‘s user capacity 
increases.   
To estimate the capacity consumed for a thin LUN follow this rule of thumb:  
Consumed capacity = (User Consumed Capacity * 1.02) + 3GB. 
For example, a thin LUN with 50 0GB of user data (User Consumed Capacity) written consumes 513 GB 
((500 GB * 1.02) +3 GB) from the pool. 
Any size thick LUN will likewise consume additional pool capacity beyond the User Capacity selected.  
However, because thick LUNs reserve their capacity, they expose the full metadata immediately in the 
reported consumed capacity from the pool.  To estimate the capacity consumed for a thick LUN follow the 
same rule for thin LUNs. 
Storage System Best Practices 
Performance     
69
Plan ahead for metadata capacity usage when provisioning the pool.  Two pools with 10 LUNs each have 
higher pool capacity utilization than one pool with 20 LUNs.  With multi-terabyte pools the percentage of 
the pools capacity used for metadata shrinks to less than 1% and should not be a concern. With small 
capacity pools the percentage of capacity used by metadata may be a considerable amount.   Create pools 
with enough initial capacity to account for metadata usage and any initial user data for the planned number 
of LUNs.  In addition, be generous in allocating capacity to a created thin LUN. This will ensure the highest 
percentage of pool capacity utilization.  
Fully Automated Storage Tiering (FAST) Virtual Provisioning  
Storage systems with FLARE 30.0 or later support the optionally licensable Fully Automated Storage 
Tiering (FAST) feature.   
FAST provides tiered LUN-based storage by relocating heavily accessed data onto the highest performing 
drives in a pool.  In-use, infrequently accessed data may be moved to higher-capacity drives with more 
modest performance if there is not enough capacity available on the high-performance tier.  The relocations 
are performed automatically in the background and require no operator intervention. FAST applies to pools 
only. It requires its LUNs be part of a single pool. FAST supports both thick and thin LUNs.  
FAST collects statistics on the accesses and rate of access for LUN data and relocates subsets of that data as 
determined by user policy settings on the LUN so the most frequently accessed data is stored on higher-
performance storage devices. An example would be relocating heavily used data from SATA to Fibre 
Channel drives.  This provides lower host response time for I/O.  Less frequently accessed data may be 
pushed to lower-performance, high-capacity storage if the higher-performance tiers are full.  Users can 
monitor and control the timing and the capacity of the data relocation to balance its effect on overall storage 
system performance.   
FAST tiers 
FAST tiers are based on drive type.  There are three types of tiers supported where all drives in the tier are 
made up of that type:  
Flash drive  
Fibre Channel 
SATA  
Drives of the same type, with different capacities and speeds, may be provisioned in the same tiers; 
however, this is not recommended.  Mixing drives of different capacities and speeds results in varying I/O 
response times within the tier.  This results in an overall less predictable host response time. 
The performance of a FAST tier is dependent on the workload‘s I/O characteristics and the tier‘s 
provisioning.  Performance can range from very high to quite modest.  For example, the highest FAST 
performance is with a small-block random workload to a Flash drive-based tier.  More modest performance  
results from a small-block random workload to a SATA-based tier.  The capacity of a tier is typically the 
inverse of its performance.  That is, Flash-drive-based tiers have fewer, more modest capacity drives.  A 
SATA-based tier is likely to have a larger number of high-capacity drives.  For example, a three-tiered 
FAST pool may have a capacity distribution of: 
5% Flash drives 
20% Fibre Channel drives  
75% SATA drives 
Storage System Best Practices 
70
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
For example, consider a 10 TB three-tiered pool. The capacity allocation would likely be 500 GB 
contributed by Flash drives, 2 TB contributed by Fibre Channel drives, and 7.5 TB by SATA drives.   
If Flash 
drives aren‘t available for a pool tier, create a two
-tiered pool, then increase the Fibre Channel tier 
to be 25 percent of the total LUN capacity. 
A Virtual Provisioning pool can be partitioned into the following number of tiers, based on the composition 
of the pool‘s drives:
Three tiers: Flash drive, Fibre Channel, and SATA 
Three tiers require all the supported drive types to be present in the pool.  This tiering structure provides the 
highest to moderate performance depending on the workload.  We recommend that you consider using Flash 
drives as a FAST Cache with a two-tiered pool before using Flash drives to create a third tier. 
Two tiers: Flash and Fibre Channel - Highest performance   
This configuration gives the highest performance when the tiers are 
provisioned with the CLARiiON‘s 
highest-performing drives. We recommend that you consider using FAST Cache with a single-tiered pool 
before using Flash drives in a two-tiered pool. 
Two tiers: Flash and SATA - High performance   
When configuring this way, t
he Flash tier must be large enough in capacity to contain the workload(s)‘ most 
actively accessed data. Configuring the Flash tier to be slightly larger than the working set‘s capacity is 
preferable. In this configuration, placement of new data or access to data that has found its way onto SATA 
drives due to lower activity must be tolerated by the application until that data can be migrated to the higher 
tier. 
Two tiers: Fibre Channel and SATA - Moderate performance with highest potential capacity 
This is the recommended FAST provisioning.  It has modest performance for large amounts of infrequently 
used data stored on large-capacity SATA drives, and high performance for I/O on frequently used data on 
Fibre Channel drives.  Use a 20 percent Fibre Channel with an 80 percent SATA drive capacity allocation.  
Use the Highest allocation method with this configuration.  Additional performance can be achieved when 
FAST Cache is enabled for this pool.  Approximately 5 percent of the pool‘s capacity should be replicat
ed 
by FAST Cache capacity. 
Single tier: Flash, Fibre Channel or SATA - High to modest performance 
Single tiering is the result of having the pool provisioned with drives of all the same type.  The performance 
of single tier provisioning ranges from the highest to the most modest performance, depending on the type 
of drive used.  Single tiering has the most predictable performance, because there is no tier warm-up or 
relocation.  Its pool-based provisioning has the benefit of ease of provisioning over traditional RAID groups 
and LUNs.  
Tier configuration: Initial data placement  
When pool LUNs are created with FAST, there are several options available for data placement.  When a 
pool LUN is created, its placement mode must be set.  Changing a LUN‘s placement 
from its original 
setting may result in relocation of data to adjacent tiers as long as that tier has less than 90 percent in-use 
capacity.  The change takes effect in the next scheduled relocation interval. 
Documents you may be interested
Documents you may be interested