Storage System Best Practices 
Performance     
81
The type (random or sequential) can affect the performance.  FAST Cache is designed for optimizing 
random I/O that has a degree of locality.  Workloads with significant sequential I/O are not good candidates 
for FAST Cache. The effectiveness of the st
orage system‘s primary cache in reading ahead already accounts 
for high performance of sequential reads.  Likewise sequential writes are typically handled with very 
efficient direct-to-disk processing. Note that a truly random I/O workload would have low locality.  
Larger caches hold more data, which increases the chance of a cache hit.  Hits are when a read or write 
request can be serviced by the FAST Cache‘s Flash drives.  A miss is a request serviced by the 
CLARiiON‘s mechanical hard drives.  Cache hits 
within the FAST Cache have a very low response time 
compared to typical storage access. 
FAST Cache and LUNs 
When FAST Cache is enabled, it is enabled by default for all LUNs and pools provisioned on the storage 
system.  Some LUNs will not benefit from the use of FAST Cache, or the FAST Cache may not have the 
provisioned capacity to optimally service every LUN and pool on the storage system.  It may be necessary 
to manually disable FAST Caching on selected LUNs and pools to improve overall caching effectiveness. 
FAST Cache can be applied to any LUN in a storage system. It is not recommended to use FAST Cache 
with LUNs made up of Flash drive-based RAID groups.  If a LUN (or component LUNs of a metaLUN) is 
created in a RAID group, FAST Cache is enabled or disabled at the individual LUN (or component LUN) 
level. If a LUN is created in a storage pool, FAST Cache must be configured at the pool level.   
FAST Cache is disabled for all LUNs and storage pools that were created before the FAST Cache enabler 
was installed (through an NDU process). After installing the FAST Cache enabler, the existing LUNs and 
storage pools will have FAST Cache disabled, but FAST Cache will be enabled (by default) on new LUNs 
and storage pools. 
Note that not all LUNs will not benefit from FAST Cache, for example, transaction logs.  These types of 
LUNs should be excluded from the FAST Cache. 
FAST Cache warm-up 
Warm-up is the filling of the FAST Cache with candidate data.  FAST Cache needs to be completely 
warmed up for optimal performance.  The efficient operation of the FAST Cache depends on that locality; 
the higher the locality the higher the caching efficiency. Likewise, the time it takes for the cache to warm up 
depends on locality in the workload.   
Host response time is determined by t
he ―hit rate‖ in the FAST Cache.  In the FAST Cache, chunks of data 
are temporarily copied from the specified LUNs located on mechanical drives to the private LUNs on the 
Flash drives that make up the FAST Cache.  Chunks of data are ―promoted‖ to the FAST 
Cache when it 
detects that a range of addresses has been referenced several times.  That range of address is then copied to 
FAST Cache. Once they are copied to the FAST Cache‘s Flash drives, reads and writes to any addresses in 
the transferred chunks of da
ta are taken care of from the cache‘s Flash drives.  These reads and writes result 
in FAST Cache hits.  Any reads or writes to addresses not in the FAST Cache are serviced from the LUNs 
on the mechanical drives as usual.  They are the misses.   
The lowest response time for a given workload will occur when the maximum number of active addresses 
has been copied to the FAST Cache‘s Flash drives.  That will result in the highest hit rate in FAST Cache.  
How to convert pdf to powerpoint on - software application cloud: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
How to convert pdf to powerpoint on - software application cloud: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 
82
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
A newly created or empty FAST Cache will have no hits.  Assuming the workload reads or writes the same 
addresses with a range of addresses with required frequency, promotions will be made in the CLARiiON‘s 
background processing. The hit rate increases as more blocks are promoted.  This is the cache "warm-up." 
The FAST Cache does not have to be "full" to generate a low host response time.  However, for optimal 
performance, a large percentage of the application‘s active working set needs to have been promoted to the 
FAST Cache.  If the working set is smaller than the FAST Cache, a wide range of warm-up times are 
possible.  Warm-up may take several minutes to several hours; it all depends on the pattern of the read and 
write requests.  If the working set is larger than the FAST Cache, there may be very few hits or reuses of 
addresses in the FAST Cache.  This is because they may not be hit before they are pushed out of the cache 
by the promotions of other address ranges.     
FAST Cache provisioning 
Flash drives are provisioned as a FAST Cache to improve the performance of FLARE LUNs or the LUNs in 
one or more pools.  Within the available maximum FAST Cache size for the storage system, the FAST 
Cache should be large enough in capacity to contain an application‘s working data set.  
FAST Cache consists of a RAID level 1 provisioning of multiple Flash drives.  It provides both read and 
write caching.  In addition, this type of provisioning has data protection. 
In addition, the capacity of the FAST Cache and the number of Flash drives used to provision the cache are 
storage system-dependent. Table 26 shows the supported FAST Cache configurations, the maximum 
number of number of Flash drives per configuration, and the FAST Cache capacity that results.   
Note that only the Flash drive configurations shown in the table are supported. Each FAST Cache size 
(capacity) requires a corresponding sizing of SP memory pages that will be dedicated to the Flash Cache 
metadata. This changes the memory allocations of other CLARiiON features.  Only the drive configurations 
shown in the table are qualified. 
Table 26  FAST Cache Maximum Flash drives per Storage System by Drive Capacity, FLARE Rev. 30.0 
FLASH 
DRIVE 
CAPACITY 
CX4-120 
CX4-240 
CX4-480 
CX4-960 
FAST 
CACHE 
RAW 
CAPACITY 
(GB) 
200 GB 
20 
2000 
10 
1000 
800 
100 GB 
400 
200 
100 
73 GB 
292 
146 
73 
See the 
Hot sparing
section for the implications of hot spares with FAST Cache.
software application cloud:Online Convert PowerPoint to PDF file. Best free online export
Download Free Trial. Convert a PPTX/PPT File to PDF. Then just wait until the conversion from Powerpoint to PDF is complete and download the file.
www.rasteredge.com
software application cloud:C# PDF Convert to Jpeg SDK: Convert PDF to JPEG images in C#.net
C# PDF - Convert PDF to JPEG in C#.NET. C#.NET PDF to JPEG Converting & Conversion Control. Convert PDF to JPEG Using C#.NET. Add necessary references:
www.rasteredge.com
Storage System Best Practices 
Availability     
83
FAST Cache Actual Capacity 
The capacity of the FAST Cache will be less than the raw capacity of its drives.  This occurs because FAST 
Caches are implemented on Flash drives as LUNs.  They have the same metadata overhead as FLARE 
LUNs. For example, creating a read/write FAST Cache from a pair of 73 GB Flash drives results in a 66 GB 
FAST Cache. It creates a RAID 1, where a 66 GB LUN is allocated for SPA and a 66 GB LUN is allocated 
for SPB. Note these LUNs are a mirrored pair.  That is a total 66 GB of FAST Cache results from two 73 
GB Flash drives. 
See the 
LUN provisioning
section for a discussion of usable versus raw capacity in LUN provisioning.  
Reserved LUNs: MirrorView, SAN Copy, and SnapView 
Layered applications such as MirrorView, SAN Copy, and SnapView create reserved LUNs that may end 
up promoted into the FAST Cache.  These reserved LUNs already have optimizations for priority in the 
storage system‘s primary write cache. Disabling FAST Cache on the MirrorView write intent log (WIL) and 
the SnapView clone reserved LUNs (CPL) is recommended. This will avoid their unnecessary promotion 
into the FAST Cache.  
Disabling FAST Caching of all reserved LUNs is recommended. In general, FAST Cache does not provide a 
performance benefit to reserved (sometimes called ―private‖) LUNs.  However, promoting the contents of 
reserved LUNs into the FAST Cache also does not adversely affect overall system performance.    
Additional FAST Cache information 
Further information is available in the EMC CLARiiON and Celerra Unified FAST Cache white paper on 
Powerlink.    
Availability 
Availability refers to the storage system‗s ability to provide user access to their applications and data in the 
case of a hardware or software fault (sometimes called a degraded state or mode).  Midrange systems like 
the CLARiiON CX4 series are classified as highly available because they provide access to data with a 
single fault. Often, the performance in degraded mode is lower than during normal operation.  The 
following optimizations to the CLARiiON‘s confi
guration can improve performance under degraded mode 
scenarios. 
RAID group provisioning 
Single DAE and Multiple DAE Provisioning 
Single DAE Provisioning is the practice of restricting the placement of a RAID group within a single DAE.  
This is sometimes called horizontal provisioning.  Single DAE provisioning is the Unisphere default method 
of provisioning RAID groups.  Owing to its convenience and HA attributes, Single DAE provisioning is 
used for most CLARiiON RAID groups.  Storage administrators who follow this standard need not be 
concerned with the following section. 
In Multiple DAE Provisioning, two or more DAEs are used.  This is sometimes called vertical provisioning.  
One reason for multiple DAE provisioning is to satisfy topology requirements.  If there are not enough 
drives remaining in one DAE to configure a desired RAID topology, they are selected from one or more 
software application cloud:VB.NET PDF Convert to Jpeg SDK: Convert PDF to JPEG images in vb.
Convert PDF to Image; Convert Word to PDF; Convert Excel to PDF; Convert PowerPoint to PDF; Convert Image to PDF; Convert Jpeg to PDF;
www.rasteredge.com
software application cloud:VB.NET PDF Convert to HTML SDK: Convert PDF to html files in vb.
Convert PDF to HTML. |. Home ›› XDoc.PDF ›› VB.NET PDF: PDF to HTML. Convert PDF to HTML in VB.NET Demo Code. Add necessary references:
www.rasteredge.com
Storage System Best Practices 
84
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
other DAEs.  The resulting configuration may or may not span buses depending on the array model and 
drive placement. 
Multiple DAE provisioning can also be used to satisfy performance requirements  specifically related to bus 
behavior. The RAID group is intentionally configured across multiple DAEs in order to gain parallel access 
to multiple buses on the storage system models that have more than one bus.  These cases arise when: 
There are well-defined bandwidth goals that require careful load distribution 
Bursting host activity is known to cause bus bottlenecks 
Heavy write cache destage operations on a RAID group interfere with host reads 
Heavy large block I/O requests on a bus interfere with small block I/O response time 
In previous CLARiiON implementations, some designers improved LUN availability in the event of a link 
controller card (LCC) failure through multiple DAE provisioning.  The LCC is the device that connects a 
tray of drives to an SP‘s bus.  Different revisions of FLARE handle an LCC failure in different ways.  
Beginning with release 26, there is a new mechanism for ensuring availability while at the same time 
maintaining data protection and decreasing the performance impact of the failure.  In release 30, the LCC 
failure mechanism was revised again. 
Prior to release 26, multiple DAE provisioning was relevant to improved availability when LCC failure 
meant loss of connectivity in configurations lacking automatic LUN failover (by PowerPath trespass, for 
instance).   Loss of connectivity was considered to be a greater problem than the resulting degraded 
performance or loss of RAID data protection.  Failover was avoided with multiple DAE provisioning by 
ensuring that sufficient drives survived an LCC outage to maintain data accessibility without a host trespass.  
For RAID 5, ―sufficient drives‖ required that no more than one drive was lost to the failure, and for RAID 
10, no more than one drive per each mirrored pair was lost.  However, the affected RAID groups were 
exposed to potentially significant performance degradation due to rebuild operations to hot spare(s) or to the 
original drive(s) upon LCC repair.  And although failover was avoided, full protection was not restored until 
the rebuild operations were complete. If insufficient hot spares were available, full data protection was not 
achieved until well after the LCC fault was repaired.  This trade-off favored availability over data 
protection. 
In the case of LCC failure, multiple DAE RAID groups without sufficient drives and all single DAE RAID 
groups required a host trespass (either manually or by automatic failover) to continue operation.  Since the 
peer SP still had complete access to the drives, rebuilds were avoided. This strategy favored data protection 
over availability where the risk was a loss of LUN connectivity at sites without host failover capability.   
Starting with FLARE release 26, an SP with an LCC failure maintains ownership, availability, and data 
protection for both single DAE RAID groups and multiple DAE RAID groups with insufficient surviving 
drives.  This is accomplished through a new internal SP request forwarding facility that diverts traffic to the 
peer SP without host trespass or front-end path modification.  For these cases, data redundancy is 
maintained via background verify (BV) rather than rebuild and all drives remain online.  However, a 
multiple DAE RAID group that has sufficient drives after the failure continues to maintain data redundancy 
via rebuild to hot spare(s) and/or the original drives upon LCC repair.  The various cases are summarized: 
software application cloud:C# powerpoint - Convert PowerPoint to PDF in C#.NET
C# PowerPoint - Convert PowerPoint to PDF in C#.NET. C# Demo: Convert PowerPoint to PDF Document. Add references: RasterEdge.Imaging.Basic.dll.
www.rasteredge.com
software application cloud:C# PDF Convert to HTML SDK: Convert PDF to html files in C#.net
Convert PDF to HTML. |. C#.NET PDF SDK - Convert PDF to HTML in C#.NET. How to Use C# .NET XDoc.PDF SDK to Convert PDF to HTML Webpage in C# .NET Program.
www.rasteredge.com
Storage System Best Practices 
Availability     
85
Table 27 LCC failure and provisioning 
Type 
FLARE revision 
Recovery operation 
Single DAE 
Pre-26 
Background Verify (BV) (SP trespass) 
Multiple DAE 
Pre-26 
Rebuild (sufficient drives, no trespass) 
-or- 
BV (insufficient drives, SP trespass) 
Single DAE 
26+ 
BV (request forwarding) 
Multiple DAE 
26+ 
Rebuild (sufficient drives, no trespass) 
-or- 
BV (request forwarding) 
Given the advantages of data protection and availability afforded by request forwarding, we generally 
recommend provisioning single DAE RAID groups.  If multiple DAE RAID groups are provisioned for 
performance reasons, we recommend configuring them to still take advantage of request forwarding in the 
event of an LCC fault.  This is accomplished by grouping drives together:   
RAID 5 should have at least two drives per bus 
RAID 6 should have three drives per bus 
RAID 1/0 should have each mirrored pair on the same bus.  
In the event of an LCC failure, it can be expected that BV and request forwarding will affect host response 
time, and that the peer SP utilization will increase during the outage in proportion to the deflected 
application load.  For RAID 5 cases where BV is invoked at the default Medium setting, the performance 
degradation is almost exclusively due to the small cost of deflecting the I/O (about 0.5 ms for a typical read) 
if the peer SP is not overloaded.   If RAID 10 LUNs incur noticeable increased read response times during 
the BV, the rate may need to be temporarily increased to High or ASAP in order to reduce its duration.  
Upon repair of the LCC, the request forwarding automatically reverts to normal operation and the BV 
continues if necessary without deflection. 
Starting with FLARE revision 30, rebuild avoidance has been incorporated.  In the event of an LCC failure, 
LUNs that span more than one DAE are not rebuilt.  Instead, FLARE  automatically uses its lower director 
to re-route around the failed LCC until it is replaced. The peer SP experiences an increase in its bus loading 
while this redirection is in use.  The storage system is in a degraded state until the failed LCC is replaced.   
Disk power saving (disk-drive Spin Down)  
Disk-drive Spin Down conserves power by spinning down drives in a RAID group when the RAID group is 
not accessed for 30 minutes, and allowing the drives to enter an idle state. In the idle state, the drives do not 
rotate and thus use less power. (A RAID group that is idle for 30 minutes or longer uses 60 percent less 
electricity.)  When an I/O request is made to a LUN whose drives are in spin down (idle) mode, the drives 
must spin up before the I/O request can be executed. A RAID group can be on idle state for any length of 
time. The storage system periodically verifies that idle RAID groups are ready for full-powered operation.  
RAID groups failing the verification are rebuilt. 
To use the Spin Down feature, you must provision a RAID group from within Unisphere or the Navisphere 
CLI, and select drives that have been qualified by EMC for this feature.  For example, all SATA drives 1 
TB and larger in capacity are qualified for Spin Down.  Spin Down can be configured at either the storage 
software application cloud:VB.NET PDF Convert to Word SDK: Convert PDF to Word library in vb.
VB.NET PDF - Convert PDF to MS Office Word in VB.NET. VB.NET Tutorial for How to Convert PDF to Word (.docx) Document in VB.NET. Best
www.rasteredge.com
software application cloud:VB.NET PDF Convert to Tiff SDK: Convert PDF to tiff images in vb.
VB.NET PDF - Convert PDF to TIFF Using VB in VB.NET. Free VB.NET Guide to Render and Convert PDF Document to TIFF in Visual Basic Class.
www.rasteredge.com
Storage System Best Practices 
86
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
system or the individual RAID group level. We recommend the storage system level. Storage-system level 
Spin Down will automatically put unbound drives and hot spares into idle. 
EMC recommends Spin Down for storage systems that support development, test, and training because 
these hosts tend to be idle at night. We also recommend Spin Down for storage systems that back up hosts. 
A host application will see an increased response time for the first I/O request to a LUN with RAID 
group(s) in standby.  It takes less then two minutes for the drives to spin up. The storage system 
administrator must consider this and the ability of the application to wait when deciding to enable the disk-
drive Spin Down feature a RAID group.  
Spin Down is not supported for a RAID group if any LUN in the RAID group is provisioned for use with 
MirrorView/A, MirrorView/S, SnapView, or SAN Copy sessions.  In addition, the Spin Down feature is not 
available for drives that are part of pool-based LUNs. 
Details on the disk-drive Spin Down feature can be found in the An Introduction to EMC CLARiiON CX4 
Disk-Drive Spin Down Technology white paper available on Powerlink. 
LUN provisioning 
Availability of LUNs is based on the underlying availability provided by the LUN‘s RAID groups, as well 
as the 
availability of caches and SPs. (The section on ―
RAID groups
‖ will help you understand the 
availability implications of creating different types and capacity RAID groups.)  However, the distribution 
of the workload‘s recovery data
across LUNs on more than one RAID group can increase the overall system 
availability.  In addition, it can increase performance by reducing the time required to execute a rebuild. 
When possible, place recovery data, such as clones and log files, on LUNs supported by RAID groups that 
do not also support the application‘s LUNs. When more than one instance of an application exists, separate 
log LUNs from their instance‘s application and application data.  Placing an application‘s recovery data on 
LUNs that ar
e not on the same RAID group as the application‘s LUNs speeds up the application recovery 
process.  This is because the recovery data is immediately available and not affected by the delay of, for 
example, a drive rebuild. 
Drive operation and planning 
The CLARiiON performs several services that, although they benefit the user, can take significant drive and 
SP resources to execute.  
There is a tradeoff between the amount of time it takes to do a LUN migration or rebuild and the effect of 
these operations on system resources and host access response time. Planning beforehand can reduce an 
adverse performance effect on the host or decrease the amount of time needed to migrate or rebuild; in a 
production environment, these goals can be mutually exclusive.  
LUN management 
There are three resources on a CLARiiON that affect overall system performance: storage processor (SP) 
CPUs, back-end buses, and RAID group drives.  The duration of LUN migrations and rebuilds needs to be 
balanced with these resources. 
The main factors affecting the duration of a drive operation are: 
Priority: Low, Medium, High, and ASAP (As Soon As Possible) 
Background workload: Storage system utilization 
Storage System Best Practices 
Availability     
87
Underlying LUN RAID group type: mirror or parity. 
RAID group hard drive type: Drive rpm speed and interface (for example, Fibre Channel or SATA). 
Priority has the largest effect on an operation‘s duration and hence system performance.  There are four 
priorities (Low, Medium, High, and ASAP) for LUN migration and rebuild 
The Low, Medium, and High 
priorities economically use the system‘s resources, but have the longest 
duration.  The ASAP priority accomplishes the operation in the shortest period of time.  However, it also 
causes a high load to be placed on the drives, and additional SP CPU load.  This will adversely affect host 
I/O performance to those drives. 
EMC encourages users to use the High, Medium, and Low settings.  In circumstances where concurrent 
access to host data has a higher priority than the time to recover, High should be used, and not ASAP. 
LUN migration  
The LUN migration facility is used to change a LUN‘s RAID group topology, move a hot LUN to a RAID 
group with lower utilization, and change a LUN‘s capacity. 
The LUN migration rate is FLARE revision-dependent.  Beginning with FLARE revision 29.0, the speed for 
migration performed at Medium and High increased dramatically, while the ASAP rate decreased.  The 
ASAP decrease provides more resources for background workload.  By default a FLARE 29.0 LUN 
migration bypasses write cache.  You can achieve even higher bandwidth by increasing the value for the 
destination LUN write-aside parameter. This enables write cache. LUN migration with write cache enabled 
is not recommended for production environments with an active workload.   
Low, Medium, High LUN migrations 
Low, Medium, and High priorities have little effect on the performance of production workloads.  These 
economical priorities implement the transfer as very large block, timed, sequential transfers.    
The following table shows the rule-of-thumb migration rate for 15k rpm Fibre Channel drives: 
Table 28 Low, Medium, and High migration rates for FLARE 29 
Priority 
Rate (MB/s) 
Low 
Medium  13 
High 
35 
The economical transfer rates are throttled by design to allow production workloads to continue executing 
without adverse performance effects during the migration process. 
ASAP migrations 
ASAP LUN migrations with default cache settings should be used with caution.  They may have an adverse 
effect on system performance.  EMC recommends that you execute at the High priority, unless migration 
time is critical. 
The ASAP setting executes the migration I/O with a minimum of delay between I/Os. Working on the SP 
itself, the inter-I/O latency is very low. The result is akin to a high-performance host running a heavy 
Storage System Best Practices 
88
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
workload against the source and destination hard drives. The workload has the characteristics of a large 
block sequential copy from the source LUN to the destination LUN.   
With FLARE 29.0 and later, the I/O write size for LUN migration is larger than the default value for LUN 
write-aside (1088 KB). If you change the write-aside value for the destination LUN to 3072 or greater, you 
can make the migration up to four times faster. The write-aside value of a destination LUN can be changed 
through the Navisphere CLI.  It cannot be changed on the destination LUN once LUN migration has been 
initiated.  
If you perform an ASAP migration through the write cache while the storage system is processing a 
workload, this may cause a forced cache flushing.  Forced cache flushing has an adverse effect on overall 
storage system performance.  The default ASAP migration settings avoid cache congestion.  Up to two 
simultaneous ASAP migrations per SP are now possible.  However, care should be taken to monitor system 
resources such as SP utilization and bus bandwidth when attempting this. 
The configuration of the underlying RAID groups that support the source and destination LUNs also affects 
migration rate. The RAID types, drive types, number of drives, and speeds of hard disks effect on the 
migration rate.  The largest and simplest factor affecting the ASAP migration rate is whether the underlying 
RAID groups are mirror or parity RAID groups, and the number of drives in the groups.   
Th
e following table shows the ASAP ―rule
-of-
thumb‖ migration rate for 15k rpm Fibre Channel and 15k 
rpm SAS drives with RAID 1/0 (3+3) groups and RAID 5 (4+1) and default write cache off settings. 
Table 29 ASAP migration rate default settings for FLARE 29 
Mirrored RAID 
rate (MB/s) 
Parity RAID 
rate (MB/s) 
Migration 
92 
55 
A LUN migration going from a smaller source LUN to a larger destination LUN is done internally in two 
steps.  First, the existing capacity is migrated to the new destination.  Then, the system initializes the new 
capacity by using its standard bind algorithm. Note that LUNs sharing the RAID group of the destination 
LUN are adversely affected by both the migration and the initialization.  
Use the following formula to estimate the time required to complete a LUN migration. 
Time: Duration of LUN migration 
Source LUN Capacity: Size of source LUN in GB 
Migration Rate: Rate of copy from source LUN to destination LUN from Table 29 or Table 30 
depending on the selected migration priority 
Destination LUN Capacity: Size of destination LUN in GB 
Initialization Rate: Speed at which new additional storage is initialized in MB/s (Table 30 for ASAP, or 
else omit) 
Time = (Source LUN Capacity * Migration Rate)  
Storage System Best Practices 
Availability     
89
Rebuilds  
A rebuild can replace the failed drive of a LUN‘s RAID group with an operational drive created from a hot 
spare.  Note that one or more LUNs may be bound to the RAID group with the failed drive. For this 
replacement to occur, there must be a hot spare available that is the correct type and size. 
If an appropriate hot spare is not available, the RAID group remains in a degraded state until the failed drive 
is replaced. Then the failed drive‘s RA
ID group rebuilds from parity or its mirror drive, depending on the 
RAID level. 
When a hot spare is used, a rebuild is a two-step process: rebuild and equalize.  They occur after the failed 
drive is replaced by the hot spare.  During the rebuild step, all LUNs on the RAID group are rebuilt to the 
hot spare either from parity or their peer.   The LUNs are in a degraded state during the rebuild. A LUN 
rebuild is a prioritized operation.  The available priorities are: ASAP, High, Medium, and Low. Rebuild 
times depend on a number of factors, including the rebuild priority, presence and location of an appropriate 
hot spare, drive type, drive size, workload, and RAID group type. Once the rebuild is complete, the LUNs 
operate normally and are not in a degraded state. During the equalize step, which occurs after the faulty 
drive is replaced, the hot spare is copied to the replacement drive.  
Low, Medium, and High priorities have little effect on the performance of production workloads Table 30 
shows the rule-of-thumb rebuild rate for 15k rpm Fibre Channel drives with RAID 5 (4+1) and RAID 1/0 
(3+3) groups. 
Table 30 Economical mirrored and parity RAID Fibre Channel hard drive rebuild rates 
Priority 
Parity RAID 
rate (MB/s) 
Low 
Medium  6 
High 
13 
The economical transfer rates are throttled by design to allow production workloads to continue executing 
without adverse performance effects during the rebuild process.  
The ASAP priority completes a rebuild in the least amount of time.  ASAP rebuilds may have an adverse 
effect on the performance of other I/Os to its RAID group. Large RAID group rebuilds can also affect other 
I/O sharing the same bus(es). EMC recommends executing at the High priority, unless rebuild time is 
critical.  
An ASAP rebuild has different rates depending on the RAID type, the hard drive type, and for parity RAID 
types, the number of drives in the RAID group. It also depends on the location of the drives 
a rebuild of a 
Parity group at ASAP engages all the drives in the group at a high rate, and the aggregate bandwidth can 
approach or even hit the maximum bandwidth of a FC bus. If all drives are on one bus, then the rebuild rate 
may be limited by bus bandwidth. 
Storage System Best Practices 
90
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
Table 31 shows RAID type dependent rates.   
Table 31 ASAP mirrored and parity RAID Fibre Channel hard drive rebuild rates with no load  
Mirrored RAID 
rate (MB/s) 
Parity RAID 5 rate 
(MB/s) 
Rebuild 
83 
73 
The following table shows the hard drive type speed adjustment. 
Table 32 ASAP hard drive rebuild speed adjustment 
Hard drive type 
Rebuild  
speed 
multiplier 
15k rpm Fibre 
Channel 
1.0 
15k rpm SAS 
1.0 
10k rpm Fibre 
Channel 
1.33 
7.5k rpm SATA 
1.54 
5.4k rpm SATA 
1.60 
Flash drive 
0.7 
Parity type RAID 6 groups require more time to rebuild than parity type RAID 5 groups with the same 
number of drives.  This difference in time decreases as the number of drives in the RAID group increases, 
due to the bus limitation discussed above.  Generally, unless they are distributed across multiple back-end 
buses, larger parity RAID groups build more slowly than smaller groups.  Use the following table to 
calculate the effects of RAID group size on rebuild rate when all drives are located on a single back-end 
bus.  Substitute the value in this table for the rebuild rate in Table 33. 
Table 33 Parity RAID rebuild rate for RAID group size 
RAID 
group 
size 
(drives) 
RAID 5 
MB/s 
RAID 6 
MB/s 
66.0 
62.0 
≤ 9 
40.0 
50.0 
≤ 12 
32.0 
30.0 
≥ 15 
25.0 
23.0 
Note the values given in the table are an average number.  A greater or lesser rebuild rate will be observed 
depending on the provisioning of the RAID group underlying the LUN.  For example, a LUN with drives on 
multiple back-end buses has a higher rebuild rate than a LUN with drives on a single bus. 
Documents you may be interested
Documents you may be interested