Storage System Best Practices 
Performance     
51
When to use RAID 3  
For workloads characterized by large block sequential reads, RAID 3 delivers several MB/s of higher 
bandwidth than the alternatives.  RAID 3 delivers the highest read bandwidth under the following 
conditions: 
Drives create the bottleneck, such as when there are a small number of drives for each back-end loop. 
The file system is not fragmented or is using raw storage. 
The block size is 64 KB or greater. 
RAID 3 can be used effectively in backup-to-disk applications.  In this case, configure RAID groups as 
either (4+1) or (8+1).  Do not use more than five backup streams per LUN.   
In general, RAID 5 usage is recommended over RAID 3.  RAID 3 should only be used for highly sequential 
I/O workloads, because RAID 3 can bottleneck at the parity drive on random writes.  Also, when more than 
one RAID 3 group is actively running sequential reads on a back-end bus, the bus can rapidly become the 
bottleneck and performance is no different from RAID 5. 
When to use RAID 5 
RAID 5 is favored for messaging, data mining, medium-performance media serving, and RDBMS 
implementations in which the DBA is effectively using read-ahead and write-behind.  If the host OS and 
HBA are capable of greater than 64 KB transfers, RAID 5 is a compelling choice.  These following 
applications are ideal for RAID 5: 
Random workloads with modest IOPS-per-gigabyte requirements 
High performance random I/O where writes are less than 30 percent of the workload 
A DSS database in which access is sequential (performing statistical analysis on sales records) 
Any RDBMS tablespace where record size is larger than 64 KB and access is random (personnel records 
with binary content, such as photographs) 
RDBMS log activity 
Messaging applications 
Video/media 
RAID 5 is the recommended RAID level for Flash, Fibre Channel, and SAS drives.  It has the best ratio of 
usable to raw capacity for parity-protected RAID groups.  Provision RAID 5 level groups to be at least four 
drives (3+1) and larger. The preferred RAID grouping is five drives (4+1).  This size offers the best 
compromise of capacity, performance, and availability for the largest number of workloads.   
When to use RAID 6 
RAID 6 offers increased protection against media failures and simultaneous double drive failures in a parity 
RAID group.  It has similar performance to RAID 5, but requires additional storage for the additional parity 
calculated.  This additional storage is equivalent to adding an additional drive that is not available for data 
storage, to the RAID group.   
We strongly recommend using RAID 6 with high-capacity SATA drives.  High capacity is 1 TB or greater 
in capacity.  In particular, when high-capacity SATA drives are used in Virtual Provisioning pools, they 
should be configured in RAID 6.    
Add pdf to powerpoint slide - application software 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
Add pdf to powerpoint slide - application software 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 
52
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
RAID 6 groups can be four to 16 drives.  A small group is up to six drives (4+2).  A medium group is up to 
12 drives (10+2), with large groups being the remainder.  Small groups stream well.  However, small 
random writes de-stage slowly and can adversely affect the efficiency of the system write cache.  Medium-
sized groups perform well for both sequential and random workloads.  The optimal RAID 6 groups are 10 
drive (8+2) and 12 drive (10+2) sized.  These groups have the best compromise of user capacity over 
capacity used for parity and performance.  
The ratio of data to parity is an important consideration when choosing a RAID 6 group size.  There is a 
reduction in user capacity equivalent of two drives with each RAID 6 group.  In addition, the additional 
parity computation has an effect on I/O performance.  For example, a five-drive RAID 5 (4+1) group would 
need to migrate to a six-drive RAID 6 (4+2) group of equal capacity drives to have the same user data 
capacity.     
Comparison of RAID 6 to RAID 5 and RAID 1/0 performance   
For random workloads, RAID 6 performs the same as RAID 5 with regard to read operations when the same 
number of drives is used.  Random writes are different.  The additional parity drive over RAID 5 increases 
the RAID 6 back-end workload by 50 percent for writes.  This affects the performance in a CLARiiON as 
the number of drives scales.  In addition, the additional overhead of RAID 6 could lead to a full cache state 
earlier than on RAID 5.  However, as long as workload can be destaged from cache without forced flushing, 
RAID 5 and RAID 6 have similar behavior from a host response time point of view. 
For sequential workloads with the same number of drives, read performance is nearly identical.  Sequential 
write workloads are about 10 percent lower for RAID 6 performance-wise. 
However, RAID 6 can survive two drive failures on any drives in the group.  This offers higher availability 
than even RAID 1/0.  The failure of a RAID 1/0 drive and its mirroring drive would be fatal for a RAID 1/0 
group.  So, RAID 6 has a capacity advantage, and availability advantage over RAID 1/0, while RAID 1/0 
continues to offer superior small-block write performance over any parity RAID type. 
Due to its double-drive protection, RAID 6 groups are well suited for the default (High) priority rebuilds, 
because of their higher availability.  Assuming that the rebuild rate is bottlenecked by a single shared bus, 
large RAID 6 groups rebuild at approximately the same rate as large RAID 5 groups.  Medium-size RAID 6 
groups require about 10 percent longer to rebuild than RAID 5 groups with the same number of data drives.  
Small-size RAID 6 groups take 25 percent longer than the same size RAID 5 group. When RAID groups are 
spread across buses, RAID 5 has a speed advantage over RAID 6 for any group size.  
Unlike the other RAID levels, FLARE revisions 30.0 and earlier do not support RAID 6 group 
defragmentation. 
RAID 6 rules of thumb  
Ten-drive (8+2) and 12-drive (10+2) RAID 6 groups have good data-to-parity ratios, IOPS capability, 
and streaming characteristics.  The 8+2 should be the first candidate for consideration due to its 512 KB 
stripe size.   
Sixteen-drive (14+2) groups have the best RAID 6 data-to-parity ratio and scale random workloads the 
best.  However, it does not run sequential streams better than eight-drive (6+2), 10-drive (8+2), and 12-
drive (10+2) RAID 6 groups. 
A six-drive RAID 6 (4+2) group has 20 percent more available IOPS than a five-drive RAID 5 (4+1) 
group.  You can consider using this as a high availability alternative to (4+1), if the read/write mix does 
application software cloud:VB.NET PowerPoint: Read, Edit and Process PPTX File
How to convert PowerPoint to PDF, render PowerPoint to and effective VB.NET solution to add desired watermark on source PowerPoint slide at specified
www.rasteredge.com
application software cloud:VB.NET PowerPoint: Process & Manipulate PPT (.pptx) Slide(s)
& editing library SDK, this VB.NET PowerPoint processing control add-on can to provide powerful & profession imaging controls, PDF document, image
www.rasteredge.com
Storage System Best Practices 
Performance     
53
not exceed drive capability.  Otherwise, use (6+2). 
The overhead of RAID 6 over RAID 5, particularly with random writes, needs to be considered when 
making replacement choices.  A 10-drive RAID 6 (8+2) group cannot service as many random writes as 
two RAID 5 groups of five drives (4+1). 
RAID 6 groups lend themselves to ―bus balancing.‖  A 10
-drive (8+2) group can be evenly distributed 
over two DAEs located on separate buses, five drives per DAE.  Twelve-drive (10+2) groups can be 
evenly distributed over three or four DAEs on separate buses. 
When to use RAID 1/0 
RAID 1/0 provides the best performance on workloads with small, random, write-intensive I/O.  A write-
intensive workload‘s operations consist of greater than 30 percent random writes. Some examples of 
random, small I/O workloads are: 
High transaction rate OLTP 
Large messaging (email) installations 
Real-time data/brokerage records 
RDBMS data tables containing small records, such as account balances being updated frequently 
RAID 1/0 also offers performance advantages during certain degraded modes.  These modes include when 
write cache is disabled or when a drive has failed in a RAID group. RAID 1/0 level groups of (4+4) have a 
good balance of capacity and performance. 
RAID group bus balancing 
There is a performance advantage to distributing in-use hard drives across as many back-end buses and as 
evenly as possible on a storage system.  
The extreme case would be to have each hard drive of a RAID group on a separate back-end bus.  (This is 
sometimes referred to as Vertical Provisioning
.)  This often is not practical given the storage system‘s back
-
end configuration.  Not all storage systems models have the number of back-end resources for this type of 
distribution.  Finally, provisioning in this fashion is time consuming to set up and maintain; it is not 
recommended 
An easier and more practical recommendation is to distribute RAID groups across back-end buses as evenly 
as possible.  In round-robin order define each RAID group to be on a separate bus.  (This is referred to as 
Horizontal Provisioning.)  Large RAID groups, and RAID 1/0 groups used for the highest availability, 
benefit from being distributed over two back-end buses, as explained below. 
Note that vertical and horizontal provisioning techniques described do not apply to the automated and labor-
saving Virtual Provisioning feature.  
For example, a CX4-960 has eight back-end buses per storage processor, and the storage to be placed on the 
system is expected to be uniform  I/O, meaning it will be either all random I/O or all sequential I/O.  If 
initially eight RAID groups of the same size and expected IOPS load are required, place one RAID group on 
each of the storage processor‘s buses. 
The exception to the rule is workloads that are not uniform.  In that case, a subset of the available buses can 
be used for drives servicing each type I/O.  For example, random I/O on one set of buses, and another set for 
sequential loads. 
application software cloud:C# PowerPoint - How to Process PowerPoint
With our C#.NET PowerPoint control, developers are able to split a PowerPoint into two or more small files. Add & Insert PowerPoint Page/Slide in C#.
www.rasteredge.com
application software cloud:VB.NET PowerPoint: Edit PowerPoint Slide; Insert, Add or Delete
NET PowerPoint slide modifying control add-on enables view more VB.NET PowerPoint slide processing functions & profession imaging controls, PDF document, image
www.rasteredge.com
Storage System Best Practices 
54
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
Dual drive ownership 
Dual ownership by either storage system SP of hard drives is supported by the CLARiiON CX4.  All hard 
drives are dual ported and can accept I/O from both SPs at the same time. 
Dual ownership may result in less predictable drive behavior than single ownership.  Each SP operates 
somewhat independently when issuing requests to any drive.  Dual ownership may subject the drives to 
deeper queue usage.  This may result in higher response times than single ownership.  However, dual 
ownership is valid in certain circumstances. For example, when creating metaLUNs over large drive pools, 
dual ownership may be required to get an even distribution of load over the back-end buses. 
In summary, single ownership of a drive is preferred.  However, if maximum throughput is required through 
data distribution, drives can be configured with dual ownership.   
Binding 
There are different ways to bind drives to increase performance and availability.  The dependency is with 
the type of RAID group (parity or mirror) involved in the binding. 
Implementing the following binding recommendations requires familiarity with the Navisphere Command 
Line Interface (CLI); specifically with the 
command.  To learn about CLI commands refer to the 
Navisphere Command Line Interface (CLI) Reference available on EMC Powerlink. 
Binding across DAEs 
Binding of drives across DAEs on the same back-end bus has a slight availability advantage.   The 
advantage is dependent on the RAID configuration, and in all cases the differences are slight. 
Parity RAID groups (RAID 3, RAID 5, RAID 6)  
Binding parity RAID groups so each drive is in a separate DAE does not help performance. However, there 
is a small increase in data availability in this approach.  Binding like this can be unwieldy and time 
consuming; if very high availability is required, use RAID 1/0. 
Mirrored RAID groups (RAID 1, RAID 1/0)  
There is no advantage in binding a RAID 1/0 group in more than two DAEs, but it is not harmful in any 
way.   
Binding across back-end buses 
All CX4 models except the CX4-120 and the AX4-5 have more than one set of dual back-end FC loops for 
attaching to their DAEs.  A RAID group can be made up of drives from one, two, or all buses. The standard 
racking of DAEs alternates the buses across adjacent DAEs, with the DPE or first DAE being bus 0, the 
next DAE bus 1, and so on. With a multibus model CLARiiON that has standard racking, splitting a RAID 
group‘s drives between adjacent DAEs places them on separate
buses. 
Parity RAID groups  
Parity RAID groups of 10 drives or more benefit from binding across two buses, as this helps reduce rebuild 
times. For example, when you bind a 10-drive (8+2) RAID level 6 group, bind five drives in one DAE, and 
bind the remaining five drives in another DAE that is on a different bus. 
application software cloud:VB.NET PowerPoint: Read & Scan Barcode Image from PPT Slide
PDF-417 barcode scanning SDK to detect PDF-417 barcode How to customize VB.NET PowerPoint QR Code barcode scanning VB.NET PPT barcode scanner add-on to detect
www.rasteredge.com
application software cloud:VB.NET PowerPoint: Convert & Render PPT into PDF Document
to convert one certain PowerPoint slide or a specified range of slides into .pdf document format using this VB.NET PowerPoint to PDF conversion library add-on.
www.rasteredge.com
Storage System Best Practices 
Performance     
55
Navisphere CLI usage to bind across buses 
Binding RAID groups across buses requires the use of the Navisphere CLI to configure the RAID group or 
define a dedicated LUN.  (The Unisphere wizard does not automatically perform this.)  When designating 
the drives, Navisphere CLI uses the drive ordering given in the 
or bind command to create 
Primary0, Mirror0, Primary1, Mirror1, and so on, in order. Drives are designated in Bus_Enclosure_Disk 
notation.  The following example demonstrates binding the first two drives from enclosure on each bus: 
Navicli –h <ip address> createrg 55  0_1_0  1_1_0  0_1_1  1_1_1 
Binding with DAE0 drives 
In a total power-fail scenario, the standby power supply (SPS) supplies battery-backed power to the SPs and 
the enclosure containing the vault drives. This allows the storage system to save the contents of the write 
cache to drives. 
However, the power to the non-vault storage system DAEs is not maintained. When the storage system 
reboots, LUNs with I/Os outstanding are checked, using the background verify (BV) process.  This checks 
to make sure that there were no writes in progress (during the power fail) that resulted in partial 
completions.  
BV is a prioritized operation.  The operation loads the storage system at ASAP, High, Medium, and Low 
rates in much the same way that rebuild operations affect the storage system, although at about half the 
drive rates found in rebuilds.   The default priority for BV is Medium.  This setting has only a modest effect 
on production workloads, especially during recovery from an SP outage. 
In the event of a drive failure, a LUN bound with drives in the vault enclosure (DPE, enclosure 0, or the first 
DAE, depending on the CLARiiON model) and drives outside the vault enclosure may require a rebuild. To 
avoid a rebuild on boot, create groups with all drives either in or out of the vault enclosure.  
If groups are split, follow these guidelines: 
Do not split RAID 1 groups across the vault enclosure and another DAE. 
For RAID 5, make sure at least two drives are outside the vault enclosure. 
For RAID 6, make sure at least three drives are outside the vault enclosure 
For RAID 1/0, make sure at least one mirror (both the primary and secondary drive in a pair) is outside 
the vault enclosure. 
LUN provisioning 
LUNs are a logical structure overlaid on the physical RAID group.  As with the underlying RAID group and 
its drives, when provisioning a LUN on a storage system you need to consider the workload‘s pr
imary I/O 
type, capacity requirements, and the LUN‘s utilization.  The section ―
RAID groups
‖ on page 
49 will help 
you understand the performance implications of creating different types and capacity RAID groups. 
When large capacity LUNs or LUN expansion is needed, use metaLUNs or storage pools. (For more 
information, see the 
MetaLUNs
‖ section and the ―
Virtual Provisioning: thin and thick LUNs
‖ sectio
n). 
LUN provisioning by I/O type 
In a workload environment characterized by random I/O, it is prudent to distribute a workload‘s LUNs 
across as many RAID groups as is practical given the available drives and configured RAID groups. 
application software cloud:VB.NET PowerPoint: VB Code to Draw and Create Annotation on PPT
for limitations (other documents are compatible, including PDF, TIFF, MS to install and use Microsoft PowerPoint software and what would you do to add and draw
www.rasteredge.com
application software cloud:VB.NET PowerPoint: Add Image to PowerPoint Document Slide/Page
InsertPage" and "DeletePage" to add, insert or delete any certain PowerPoint slide without affecting the & profession imaging controls, PDF document, tiff
www.rasteredge.com
Storage System Best Practices 
56
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
In a workload characteri
zed by sequential I/O, it is advantageous to distribute the workload‘s LUNs across 
as few RAID groups as possible to keep the RAID groups performing the same I/O type. 
When more than one I/O type is handled by the storage system, the LUNs supporting the different I/O types 
should be kept as separate as possible.  That is, if possible, do not put LUNs supporting workloads with 
mostly random I/O on the same RAID group as LUNs supporting workloads with most sequential I/Os. 
LUN provisioning by percentage utilization 
Ideally, all the active RAID groups in the storage system should have a similar percentage of utilization.  
(LUNs are a host visible logical construct built upon one or more RAID groups create RAID group 
utilization.) This would be the most efficien
t use of the storage system‘s resources.  However, this is rarely 
the case.  At any time, some LUNs may be hot LUN s, and other LUNs may be essentially idle.  A hot LUN 
is a LUN participating in a workload causing its underlying RAID group to have drive utilization 
significantly higher than the average of similarly tasked RAID groups on the storage system.  A leveling of 
RAID group drive utilization across the storage system should be sought to get the best performance from 
the storage system. 
Unisphere Analyzer provides information on drive utilization to determine how to distribute the LUNs 
across the storage system.  Information on how to use Unisphere Analyzer can be found in the EMC 
Navisphere Analyzer Administrator’s Guide
, available on Powerlink.   
When more than one LUN shares a RAID group, try to achieve an average utilization by matching high-
utilization with low-utilization LUNs, or average-utilization with other average-utilization LUNs on RAID 
groups to achieve an overall average RAID group utilization for the LUNs on the storage system.  When the 
workload is primarily random, the averaging will be across as many RAID groups as is practical to meet 
capacity, availability, and performance requirements.  When the workload is sequential, the averaging will 
be across as few as is practical to meet capacity, availability, and performance requirements. 
Another way to distribute LUNs is by when they are used (temporal allocation ).  It may be that not all 
LUNs are constantly active.  For example, LUNs supporting a business day workload from 8 A.M. to 8 P.M. 
will have their highest utilization during this period.  They may have either low utilization or be idle for 
much of the time outside of this time period.  To achieve an overall average utilization, put LUNs that are 
active at different times over a 24-hour period in the same RAID group. 
If high utilization LUNs from the same workload must be placed in the same RAID group together, place 
them next to each other on the RAID group (that is, without any intervening LUNs between them).  This 
will minimize the drive seek distance (time) and get the highest performance between these highly utilized 
LUNs.  The Navisphere CLI is needed to perform this operation. 
MetaLUNs 
Multi-RAID group metaLUNs increase available IOPS by adding drives.  MetaLUNs also allow for 
provisioning LUNs with increased storage capacity over single RAID group hosted LUNs.   
An in-depth discussion of metaLUNs, including how to create them, can be found in the EMC CLARiiON 
MetaLUNs - A Detailed Review white paper available on Powerlink. 
On a CLARiiON storage system, metaLUNs are implemented as a layer above the RAID groups.  They are 
functionally similar to the application of a volume manager on a host.  However, there are some important 
distinctions between metaLUNs and a volume manager.  
application software cloud:VB.NET PowerPoint: VB Codes to Create Linear and 2D Barcodes on
Here is a market-leading PowerPoint barcode add-on within VB.NET class, which means it as well as 2d barcodes QR Code, Data Matrix, PDF-417, etc.
www.rasteredge.com
application software cloud:VB.NET PowerPoint: Extract & Collect PPT Slide(s) Using VB Sample
Add(tmpFilePath1) docPathList.Add(tmpFilePath2) PPTXDocument this VB.NET PowerPoint slide processing tutorial & profession imaging controls, PDF document, image
www.rasteredge.com
Storage System Best Practices 
Performance     
57
Single SCSI target versus many 
To create a volume manager stripe, all of the component LUNs must be made accessible to the host. To 
create a metaLUN, only a single SCSI LUN is mapped to the host; the host does not see the multiple LUNs 
that make up the metaLUN. This benefits the administrator when: 
Their hosts have limited LUNs available due to OS limits 
Adding LUNs to their host causes a renumbering of SCSI devices; often a kernel rebuild is necessary to 
clean up the device entries 
In these cases, using a metaLUN instead of a volume manager simplifies administration on the host. 
When there is no volume manager 
Not all operating systems have volume manager support. Microsoft Windows Server 2000/2003 clusters 
using Microsoft Cluster Services (MSCS) cannot make use of dynamic disks. In this case, metaLUNs allow 
you to provide expandable, striped, and/or concatenated volumes for these systems. 
Replication of the volume 
If the volume is to be replicated on the storag
e system using the CLARiiON layered products (SnapView™, 
MirrorView™, or SAN Copy™), a usable image requires consistent handling of splits. A metaLUN will 
simplify replication. 
Volume access sharing 
When a striped or concatenated volume must allow shared access between hosts, and a volume manager will 
not permit shared access, a metaLUN can be used. The metaLUN is placed in both hosts‘ storage groups.
Storage processor bandwidth 
An important distinction between a volume manager volume and a metaLUN is that a metaLUN is 
addressed entirely by one storage processor on one CLARiiON storage system. If very high bandwidth is 
required for a single volume, a volume manager is still the best approach, as the volume can be built from 
LUNs on different SPs. A volume manager allows the user to access storage at an aggregate bandwidth of 
many storage processors. 
Volume managers and concurrency 
As pointed out in the ―
Plaids for high bandwidth
‖ section, the use of a host
-striped volume has the effect of 
multithreading requests consisting of more than one volume stripe segment. This increases concurrency to 
the storage system. There is no multithreading effect with a metaLUN, as the multiplexing of the component 
LUNs is done on the storage system. 
MetaLUN usage and recommendations 
The three types of metaLUNs are striped, concatenated, and hybrid. This section presents general 
recommendations.  
Component LUN type 
When binding a LUN to be included in a metaLUN, the type of LUN you bind should reflect the I/O pattern 
expected for the metaLUN. Match the I/O pattern with the recommendations made in this paper for different 
RAID types.  
Storage System Best Practices 
58
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
When binding component LUNs, the following recommendations apply: 
Always use the default stripe element size (128 blocks) when binding LUNs for use in metaLUNs.  
Always activate read and write cache. Use the default setting. 
Ensure the write-aside size for component LUNs is the default 2048.  
Use RAID 5 groups of at least four drives (3+1) and larger (we recommend 4+1). 
Use RAID 1/0 groups of at least four drives (2+2) and larger. 
Use RAID 6 groups of at least eight drives (6+2) where you expect to expand the RAID groups in the 
future. Otherwise use the recommended groups of 10 drives (8+2). 
Do not use the component LUN offset to adjust for stripe alignment. MetaLUNs have their own offset 
value. 
MetaLUN type 
In general, use striped metaLUN components wherever possible as they yield the most predictable 
performance. Concatenation of a single LUN to a metaLUN is intended for convenience; this may be 
appropriate for expanding a volume that is not performance sensitive. 
Hybrid metaLUN combines concatenation with striping. This approach is used to overcome the cost of 
striped expansion. A striped metaLUN can be expanded by concatenating another striped component. This 
preserves the predictable performance of a striped component, and allows an expansion of a striped 
metaLUN without restriping existing data (performance is affected while the restriping operation is under 
way). The next figure illustrates this point. 
20 GB
20 GB
20 GB
20 GB
10 GB
10 GB
10 GB
10 GB
+
80 GB 
original striped metaLUN + 40GB striped component
20 GB
20 GB
20 GB
20 GB
10 GB
10 GB
10 GB
10 GB
+
80 GB 
original striped metaLUN + 40GB striped component
Figure 3  Hybrid striped metaLUN   
Ideally, the LUNs in the expansion stripe set are distributed over RAID groups of the same RAID type and 
geometry as the original striped component. The most direct way to achieve this is to use the same RAID 
groups as the base component. The RAID groups are expanded first, in order to make space available.  
MetaLUN stripe multiplier 
The stripe multiplier determines the metaLUN stripe segment size: 
MetaLUN stripe segment size = stripe multiplier * base LUN stripe size 
The largest I/O a metaLUN can receive, will be the smaller of  either a 2 MB (due to cache limitations) and 
the metaLUN stripe segment size. 
Both high bandwidth performance and random distribution call for metaLUN stripe elements of about 1 
MB. Also, the underlying RAID groups may be expanded. Ensure the metaLUN stripe element is big 
enough to write full stripes to expanded component LUNs.  
Use these rules to set the stripe multiplier: 
Storage System Best Practices 
Performance     
59
Unless using RAID 0, use groups of at least four drives to make up the RAID groups hosting the 
component LUNs. 
Determine the number of effective drives for the group size chosen. For example, a six-drive (3+3) 
RAID 1/0 is 3. Five-drive (4+1) RAID 5 is four. 
Select the multiplier for the number of effective drives from the metaLUN stripe multipliers table. 
Table 14  MetaLUN stripe multipliers 
Effective drives in 
component RAID group 
MetaLUN stripe 
multiplier 
MetaLUN stripe 
element 
1024 
1152 
1024 
960 - 1344 
1024 
If in doubt, use the default four (4) for the metaLUN stripe multiplier.  
For example, what is the best stripe multiplier for a metaLUN that is used for general file serving and made 
up of two five-drive (4+1) RAID 5 groups?  The ideal would be to ensure 1 MB I/Os to the metaLUN.  The 
metaLUN‘s base LUN, a 4+1, has a 256 KB (4 * 64 KB) stripe size.  Therefore, a metaLUN stripe segment 
size of four (1 MB / 256 KB) would be appropriate.  Note that four is also the default. 
MetaLUN alignment offset 
When planning to use SnapView or MirrorView with a metaLUN, leave the metaLUN alignment offset 
value at zero. Use disk utilities to adjust for partition offsets. 
MetaLUNs and rebuilds 
A single drive fai
lure in a metaLUN‘s RAID group will adversely affect the entire metaLUN‘s performance 
until the metaLUN is rebuilt.  In general, for SATA and FC drives, the increased IOPS available to multi-
RAID group metaLUNs (compared to individual RAID group LUNs) during normal operation outweigh the 
relatively infrequent rebuild penalty incurred if one of the component RAID groups experiences a drive 
failure.  For ASAP rebuild, the percentage decrease in a metaLUN‘s throughput can be roughly 
approximated by the percent
age of drives involved in the rebuilding RAID group relative to the metaLUN‘s 
full drive width.   However, if the rebuild setting is High, Medium, or Low, the rebuilding RAID group will 
itself incur less than 10 percent degradation, and the overall metaLUN will run very close to production 
speed.   
MetaLUN expansion strategies  
There are several strategies for using metaLUNs for a long-term expansion plan. To develop a strategy, first 
identify the goals. The goals of the approach presented in the following section are: 
Distribution of localized bursts of otherwise random data over many drives 
Good sequential/bandwidth performance 
Efficient use of capacity 
Storage System Best Practices 
60
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
Flexible expansion of devices 
These goals apply to the majority of metaLUN users. 
Expansion model initial configuration 
The general rules for the initial setup of this solution are shown in Figure 4. The rules are: 
Deploy the required drives for initial deployment capacity. 
Create modest-size RAID groups: 
For RAID 1/0, use four or six drives (3+3). 
For RAID 5 or RAID 3, use five drives (4+1). 
For RAID 6 use 10 drives (8+2). 
Organize the RAID groups into sets of four to eight groups. (Use more groups per set if very high rates 
of random I/O are required.) 
For each metaLUN, determine the RAID group set to which it will belong. 
Define the component LUN size for each planned metaLUN by dividing metaLUN size by the number 
of RAID groups in its RAID group set. 
Create a component LUN for each metaLUN from each RAID group in its set. 
Form metaLUNs from LUNs distributed across all the RAID groups in their respective sets.  Figure 4 is 
an example of a set of metaLUNs and their RAID group set.  
4 RAID groups, each 5-disk RAID 5
1.1 TB Useable
MetaE: 200 GB
MetaLUNs
1.1 TB
MetaF: 500 TB
MetaG: 200 GB
50 GB   * 4 LUNS
125 GB * 4 LUNS
50 GB   * 4 LUNS
50 GB   * 4 LUNS
MetaH: 200 GB
Base LUN Size
Each RAID group hosts 4 component LUNs, 
1 for each metaLUN
Group 1
Group 2
Group 3
Group 4
4 RAID groups, each 5-disk RAID 5
1.1 TB Useable
MetaE: 200 GB
MetaLUNs
1.1 TB
MetaF: 500 TB
MetaG: 200 GB
50 GB   * 4 LUNS
125 GB * 4 LUNS
50 GB   * 4 LUNS
50 GB   * 4 LUNS
MetaH: 200 GB
Base LUN Size
Each RAID group hosts 4 component LUNs, 
1 for each metaLUN
Group 1
Group 2
Group 3
Group 4
Figure 4  Initial distribution of storage for metaLUNs 
Note in Figure 4
, each metaLUN consists of one LUN per RAID group. Each LUN‘s load is evenly 
distributed across all RAID groups in the set. However, these metaLUNs are fenced off from data access to 
other RAID group sets. 
Why use RAID group sets? If we do not allow a metaLUN to extend outside of its set, we can determine a 
level of fencing, controlling interactions at the drive level. For instance, one RAID group set may be for a 
large number of file servers, while another is used for RDBMS data tables
and an ordinary pair of RAID 1 
groups may be used as the RDBMS log devices. Figure 5 illustrates this. 
Documents you may be interested
Documents you may be interested