Storage System Best Practices 
Availability     
91
When a hot spare is used for the rebuild, an additional equalize operation occurs when the faulty drive is 
replaced and the hot spare is copied to it. The equalization rate for all rebuild priorities with 15k rpm Fibre 
Channel hard drives is shown in the following table.  This rate is independent of other factors. 
Table 34 Mirrored and parity RAID Fibre Channel equalization rebuild rates 
Mirrored RAID 
rate (MB/s) 
Parity RAID 
rate (MB/s) 
Equalization 
82 
82 
Basic rebuild time calculation 
Use the following formula to estimate the time required to complete a rebuild. 
Time: Duration of rebuild 
Failed hard drive capacity: RAID group capacity utilization * hard drive size in GB 
Rebuild rate: If priority is ASAP, use the time listed in Table 32. Otherwise, use the value from Table 
34. 
Hard drive type and speed adjustment: Speed adjustment is found in Table 33. 
Equalization Rate: Speed at which the hot spare is copied to replacement for a failed drive. 
Time = ((Failed hard drive capacity * Rebuild rate) * Drive type and Speed adjustment) + ((Failed hard 
drive capacity * Equalization rate) * Drive type and Speed adjustment)) 
Note the rebuild has two parts: rebuild and the equalization.  Manual replacement of the failed hard drive 
must occur before equalization. After the rebuild the RAID group is running at full capability.  The RAID 
group is no longer in a degraded status.  The secondary equalization is an automated background process 
starting with the replacement of the failed drive.  
ASAP rebuild example calculation 
How many hours will it take to rebuild a 400 GB, 10k rpm, seven-drive (6+1) RAID 5 Fibre Channel group 
drive that is fully bound and utilized, at the ASAP priority?  Assume a quick replacement of the failed hard 
drive allowing a seamless equalization.  Assuming the LUN is bound with all the drives on the same bus and 
enclosure, the rebuild time is calculated using this equation: 
Time = ((Failed hard drive capacity * Rebuild rate) + ((Failed hard drive capacity * Equalization rate)) * 
(Drive Type and Speed adjustment) 
Where the parameters are: 
Time: Duration of rebuild in hours  
Failed Hard Drive Capacity: 400 GB  
Rebuild Rate: 66.0 MB/s (From Table 34, if this were a five-drive RAID 5 (4+1) the Rebuild Rate 
would come from Table 32)  
Drive Type and Speed Adjustment: 1.33 for 10k rpm Fibre Channel (from Table 33)  
Equalization Rate: 82.0 MB/s (from Table 35) 
Changing pdf to powerpoint - Library SDK component: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
Changing pdf to powerpoint - Library SDK component: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 
92
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
In this example the equation is: 9.9 Hrs  = ( ( 400 GB  *  (1/66.0) MB/s ) + ( 400 GB * ( (1/82.0) MB/s))  *  
(1024 MB/GB  *  (1/3600) sec/Hrs ))  *  1.33 ). 
Maintaining performance during an ASAP rebuild 
The effect of an ASAP rebuild on application performance depends on the workload mix.  There are three 
effects to consider: 
Rebuilding drive utilization  
Bus bandwidth utilization 
Relative drive queue contention 
All applications performing I/O with the rebuilding RAID group will be slower.  The rebuild will be sending 
up to eight I/Os at a time to each drive in a parity group.  If the group is a mirror, it will send eight I/Os to 
the remaining mirror.  Longer service times for the large rebuild reads and the longer queue will increase 
response time.  
Bus bandwidth utilization will affect all drives on the same bus. As bus utilization climbs, there is less 
bandwidth available for other processes. Please note that when all drives of a parity RAID group are on the 
same bus, depending on the RAID group size and drive type, a large percentage of the available bus 
bandwidth may be consumed by an ASAP rebuild.  The rebuild of large RAID groups can consume all 
available bus bandwidth.  If bandwidth-sensitive applications are executing elsewhere on the storage 
system, RAID groups should be distributed across buses.  
The contention for the drives between production and rebuild can be seen in the relative queues. Rebuild 
and equalize operations do not use the read or write cache subsystems, but they do send multiple, large I/O 
at the same time. Host I/O behavior may depend on the source pattern or on cache usage. Sequential writes 
destage from cache with multiple threads per drive with large coalesced block sizes competing with the 
rebuild operation.  Concurrent sequential writes and a rebuild slow each other about the same amount. 
Sequential reads do not generally generate a similar parallel thread load per drive. Furthermore, there is a 
reduction of sequentiality at the drive due to contending workloads. So, sequential read operations like LUN 
backups run much slower during ASAP rebuilds than when an ASAP rebuild is not executing.   
If you have an active sequential read workload on the rebuilding RAID group, the ASAP rebuild rate will be 
lower than the rates described in this section‘s tables, due to contention.  Storage system performance during 
an ASAP rebuild can be maintained by increasing the prefetch variables to favor the host read.  One option 
is to change prefetch multiplier to 32 and segment multiplier to 4.  For example, a 64 KB sequential read 
stream will prefetch 2 MB at a time in 256 KB chunks, substantially increasing the read rate during rebuild. 
Of course, if other processes are accessing those drives in normal operation, they also will be affected by the 
bias towards sequential reads. 
If the adverse performance effects of an ASAP rebuild cannot be tolerated by the workload, rebuild priority 
should be set to High, Medium, or Low.  These rebuild rates are slower than ASAP, but even at the High 
setting production workloads are only competing with the rebuild for 10 percent of the time. 
LUN and Virtual Provisioning pool initialization  
Newly bound LUNs and new Virtual Provisioning pools have their drives zeroed.  This is called 
background zeroing. Background zeroing erases any data previously written to the drive.  It provides 
Library SDK component:VB.NET Word: Word Conversion SDK for Changing Word Document into
VB.NET Word - Convert Word to PDF Using VB. How to Convert Word Document to PDF File in VB.NET Application. Visual C#. VB.NET. Home
www.rasteredge.com
Library SDK component:C# PDF Page Rotate Library: rotate PDF page permanently in C#.net
Enable batch changing PDF page orientation without other PDF reader control. Support to overwrite PDF and save rotation changes to original PDF file.
www.rasteredge.com
Storage System Best Practices 
Availability     
93
confidentiality, and pre-conditions the drives for background verification.  The background zeroing only 
occurs on drives that have previously been used. The zeroing occurs in the background, allowing the LUN 
to immediately be available.  The zeroing rate is between 20 MB/s and 50 MB/s, depending on the drive 
type. The 5.4k rpm SATA drives have a lower zeroing rate than Flash drives, which have the highest rate.       
With FLARE 29.0 and later, LUNs use Fast Bind.  Fast Bind immediately makes a LUN available for use, 
before it is completely initialized in a bind or the unused remainder of the new or the destination LUN is 
initialized in a migration.  This differs from previous FLARE versions that performed a separate 
initialization.   
The complete zeroing of large-capacity LUNs or disks in new Virtual Provisioning pools can take several 
hours.  This process may adversely affect storage system performance, particularly when many LUNs or  
maximum-size storage pools are created at the same time.  Creating large numbers of LUNs or large pools 
without pre-zeroing should be avoided while a production workload is in progress, if possible. 
The zero-ing process can be accelerated in the following ways: 
Use new drives from EMC. 
If the drives have been previously used, manually pre-zero drives before binding or pool creation. 
New drives from EMC are pre-zeroed.  New drives are automatically detected as being pre-zeroed, and are 
not ―re
-
zeroed.‖ 
Manually zeroing drives ahead of binding decreases the length of time it takes for LUNs or pools to be 
completely available.  Pre-zeroing is executed by the individual drives internally at a rate of about 100 
MB/s.  Pre-zeroing needs to be performed on the drives before they are assigned to RAID groups or pools, 
and requires use of the Navisphere CLI.  The following commands can be used to pre-zero drives: 
1.
naviseccli zerodisk –messner <disk-id> <disk-id> <disk-id> start 
2.
naviseccli zerodisk –messner <disk-id> <disk-id> <disk-id> status 
The first command ―start‖ begins the drive zeroing.  The second command ―status‖ can 
be used to monitor 
the zeroing progress. 
Note that a LUN or pool is not completely initialized until a Background Verify has been completed.  The 
bind wizard provides a ―no initial verify‖ option for FLARE LUNs; if you select this option the bind wizard 
does not execute the Background Verify.  This option is not available under Virtual Provisioning.   
Library SDK component:VB.NET PDF File Merge Library: Merge, append PDF files in vb.net
Merge Microsoft Office Word, Excel and PowerPoint data to PDF form. together and save as new PDF, without changing the previous two PDF documents at all
www.rasteredge.com
Library SDK component:C# PDF Convert to Tiff SDK: Convert PDF to tiff images in C#.net
PDF. Supports tiff compression selection. Supports for changing image size. Also supports convert PDF files to jpg, jpeg images. C#
www.rasteredge.com
Storage System Best Practices 
94
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
Library SDK component:C# PDF Password Library: add, remove, edit PDF file password in C#
Able to perform PDF file password adding, deleting and changing in Visual Studio .NET project use C# source code in .NET class. Allow
www.rasteredge.com
Library SDK component:C# TIFF: Learn to Convert MS Word, Excel, and PPT to TIFF Image
using RasterEdge.Imaging.PowerPoint; This demo code is for rendering and changing PowerPoint (.pptx) document to Tiff image. // Load your PPT (.pptx) document.
www.rasteredge.com
Introduction    
95
Chapter 5  Storage System 
Sizing and 
Performance 
Planning 
Storage sizing consists of calculating the right number of drives for capacity, and calculating the correct 
number of drives and the right storage system for performance. This chapter is included to illustrate the 
major considerations in configuring a storage system for a workload.  This chapter is not a substitute for the 
software tools available to EMC Sales and Technical Professionals providing sales support. 
Introduction 
Workload is always the primary consideration for storage system configuration.  The workload‘s 
requirements can broadly be defined as capacity and performance.   It is important to have enough storage 
capacity and I/O per second (IOPS) to satisfy the workload‘s peak requirements.  In addition, performance 
sizing and planning should take into account planned and unplanned degraded capacity and performance 
scenarios. 
Capacity 
First determine the RAID type and drive-group size.  This calculation affects capacity in parity RAID types. 
Once the number of drives is known, the performance calculation can be made. EMC personnel have tools 
to determine the exact usable capacity of a provisioned system. These tools take into account the numerous 
factors affecting final capacity, such as vault drives, the extended redundancy data stored with each sector 
on a CLARiiON storage system, hot spares, and so forth. 
Vault drives 
The first five drives in a CLARiiON contain the vault. Vault drives can be used just as any other drives on 
the system. However, vault drives have less usable capacity. When bound with other non-vault drives, all 
drives in the group are calculated to have the same capacity as the vault drives. Thus, it is more efficient for 
capacity utilization to bind the vault drives together as a group (or groups).  For vault drive performance 
considerations, refer to the 
Performance
section on page 96.   
Actual drive capacity 
Accessible capacity may vary because some operating systems use binary numbering systems for reported 
capacity. Drive manufacturers consider a gigabyte to be 1,000,000,000 bytes (base 10 gigabyte). A 
computer OS may use base 2 (binary) and a binary gigabyte is 1,073,741,824 bytes.  
Also, CLARiiON uses eight additional bytes per 512 byte sector for storing redundancy information. This 
520-byte sector reduces the usable capacity by a small margin. 
Library SDK component:VB.NET Image: How to Generate Freehand Annotation Through VB.NET
as PDF, TIFF, PNG, BMP, etc. If this VB.NET annotation library is used, you are able to create freehand line annotation in VB.NET application without changing
www.rasteredge.com
Library SDK component:VB.NET Image: Easy to Create Ellipse Annotation with VB.NET
png, gif & bmp; Add ellipse annotation to document files, like PDF & Word to customize ellipse annotation on your document or image by changing its parameters
www.rasteredge.com
Storage System Sizing and Performance Planning 
96
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
For example, a 146 GB drive has a formatted data capacity of about 133 GB and a 400 GB drive has a 
formatted data capacity of about 367 GB. 
Parity versus mirrored protection 
The use of parity or mirroring to protect data from drive failure also reduces usable storage. Mirroring 
always requires that 50 percent of total storage capacity be used to ensure data protection.  This is called 
protection capacity overhead.   
For example, a 16-drive RAID 1/0 (8+8) has a protection capacity overhead of eight hard drives.  Eight of 
the 16 drives are available for storage; the remaining eight are protection overhead.  Assume this RAID 1/0 
group is composed of formatted 146 GB (raw capacity) 15k rpm Fibre Channel drives.  The usable capacity 
of this RAID group is about 1.04 TB.  Note the difference between the actual usable capacity and the 
approximately 2.3 TB (16*146 GB) that might be assumed, if formatting and mirroring are not taken into 
account.  
The percentage of parity RAID space given to protection capacity overhead is determined by the number of 
drives in the group and the type of parity RAID used.  Parity RAID 3 and RAID 5 have a single drive 
capacity equivalent of overhead out of total drives.  RAID 6 has a two-drive equivalent overhead. 
For example, a five-drive RAID 5 (4+1) group has a 20 percent overhead.  It has the equivalent of four 
drives available for storage and the overhead of one drive for parity.  Assume this RAID 5 group is 
composed of formatted 400 GB (raw capacity) 15k rpm Fibre Channel drives.  Taking into account 
formatting and parity, this would result in a total usable capacity for this RAID group of about 1.4 TB.  
Performance 
Performance planning or forecasting is a science requiring considerable knowledge.  The threading model of 
the workload, the type of I/O (random or sequential), the I/O size, and the type of drive all affect the 
performance observed.  The EMC CLARiiON Fibre Channel Storage Fundamentals  white paper contains 
detailed information on the factors affecting performance.   
Rule-of-thumb approach 
To begin a performance estimation, a rule of thumb is used for IOPS per drive and MB/s per drive.  Use the 
guideline values provided in Table 36 or this estimate.  This is a conservative and intentionally simplistic 
measure.  Estimates of RAID group response time (for each drive), bandwidth, and throughput need to 
account for the I/O type (random, sequential, or mixed), the I/O size, and the threading model in use.  It 
should be noted this is only the beginning of an accurate performance estimate; estimates based on the rule 
of thumb are for quickly sizing a design. More accurate methods are available to EMC personnel. 
Random I/O 
Small-block (16 KB or less per request) random I/O, like those used in database applications and office 
automation systems, typically require throughput with an average response time of 20 ms or better.  At an 
average drive-queue depth of one or two, assume the following per drive throughput rates: 
Table 35 Small block random I/O by drive type
Drive type 
IOPS 
Fibre Channel 15k rpm 
180 
SAS 15k rpm 
180 
Library SDK component:VB.NET PDF File & Page Process Library SDK for vb.net, ASP.NET
creating, loading, merge and splitting PDF pages and Files, adding a page into PDF document, deleting unnecessary page from PDF file and changing the position
www.rasteredge.com
Library SDK component:C# Excel - Excel Page Processing Overview
C#.NET programming. Allow for changing the order of pages in an Excel document in .NET applications using C# language. Enable you
www.rasteredge.com
Storage System Sizing and Performance Planning 
Performance     
97
Fibre Channel 10k rpm 
140 
SATA 7.2k rpm 
80 
SATA 5.4k rpm 
40 
Flash drive 
2500 
Most installations will have more than a single thread active, but want to keep response times below 20 ms.  
To create a more conservative estimate, these response time sensitive applications may want to perform 
calculations assuming one-third fewer IOPS per FC or SAS drive.  In cases of random I/O sizes greater than 
16 KB, there will be a steady reduction in the IOPS rate.  In cases of well-behaved sequential access, the 
rate may be well double the listed IOPS for FC and SAS drives, even for large I/O sizes. 
For example, a single threaded application has one outstanding I/O request to a drive at a time.  If the 
application is doing 8 KB random reads from a 10k rpm drive, it will achieve 125 IOPS at 8 ms per I/O.  
The same application, reading a drive through 12 simultaneous threads of the same size, can achieve 240 
IOPS at 50 ms per I/O.   
When architecting for optimal response time, limit the drive throughput to about 70 percent of the 
throughput values shown in Table 36.  Optimal throughput can be achieved by relaxing response time and 
queue depth ceilings.  If a response time greater than 50 ms and a drive queue depth of eight or more is 
allowable, the table‘s drive throughput can be increased by 50 percent more IOPS per drive.
For random requests 64 KB to 512 KB, drive behavior is usually measured in bandwidth (MB/s) rather than 
IOPS.  As the block size increases, so does the per-drive bandwidth.  At a queue depth of one, assume the 
following per drive bandwidth rates: 
Table 36 Large block random bandwidth by drive type 
Drive type 
64 KB (MB/s) 
512 KB (MB/s) 
Fibre Channel 15k 
rpm 
8.0 
32.0 
SAS 15k rpm 
8.0 
32.0 
Fibre Channel 10k 
rpm 
6.0 
24.0 
SATA 7.2k rpm 
4.0 
16.0 
SATA 5.4k rpm 
2.5 
12.0 
Flash drive 
100 
100 
Note the number of threads has a big effect on bandwidth.  With a five-drive (4+1) RAID 5 LUN with a 
single thread continuously reading a random 64 KB pattern, the per-drive queue depth is only 0.2 and the 8 
MB/s bandwidth applies to the sum of the spindle activity.  In contrast, a 16-thread 64 KB random read 
pattern can achieve about 60 MB/s. 
The number of drives that can be driven concurrently at the shown rates will be limited by the available 
back-end bandwidth of the storage system. 
Storage System Sizing and Performance Planning 
98
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
Sequential I/O 
For 64 KB and greater block sizes running single thread sequential I/O, RAID group striping makes 
bandwidth independent of the drive type.  Use 30 MB/s per drive as a conservative design estimate.   
Depending upon your environment, drive bandwidth can be improved considerably though tuning.  For 
instance, by using a 16 KB cache page size, a prefetch multiplier of 16, and a segment multiplier of 16, a 
five-drive RAID 5 (4+1) can achieve 50 MB/s per drive.  If multiple threads are used, then these five drives 
can exceed the bandwidth of the back-end bus, which is about 360 MB/s.  Note this may have an adverse 
effect on other applications sharing the bus. 
Sending fewer, larger I/Os to the CLARiiON‘s ―back end‖ improves sequential I/O performance.  When 
more than one RAID group stripe is read or written, each drive in the group gets a single large I/O, which  
results in the m
ost efficient use of the CLARiiON‘s back
-end resources.  This is particularly true if SATA 
drives are the destination of the I/O.  The best sequential write I/O performance with any RAID stripe size 
occurs when the write cache page size is configured to be 
16 KB and the RAID group‘s stripe size is evenly 
divisible by that 16 KB.  This allows for up to 2 MB to be sent to the CLARiiON‘s drives from the cache in 
one operation of writing multiple RAID group stripes.  For example, with a 16 KB cache page, a RAID 5 
(4+1) with its 256 KB stripe size has eight stripes written in one operation.  Similarly, a RAID 6 (8+2) with 
its 512 KB stripe has four stripes written in one operation.  
Mixed random and sequential I/O 
In mixed loads, the pure sequential bandwidth is significantly reduced due to the head movement of the 
random load, and the random IOPS are minimally reduced due to the additional sequential IOPS.  The 
sequential stream bandwidth can be approximated using the values in Table 37and the random load can be 
approximated by using 50 percent ofTable 36
‘s IOPS.   Aggressive prefetch settings (prefetch multiplier 16, 
segment multiplier 16) improve the sequential bandwidth at the expense of the random IOPS.  Increasing 
the random load queue depth increases its IOPS at the expense of the sequential stream bandwidth. 
Performance estimate procedure 
For a quick estimate: 
Determine the workload. 
Determine the drive load. 
Determine the number of drives required. 
Determine the number and type of storage systems. 
Determining the workload 
This is often the most difficult part of the estimation. Many people do not know what the existing loads are, 
let alone load for proposed systems. Yet it is crucial for you to make a forecast as accurately as possible. 
Some sort of estimate must be made. 
The estimate must include not only the total IOPS, but also what percentage of the load is reads and what 
percentage is writes. Additionally, the predominant I/O size must be determined.  
Determining the drive load 
Note the IOPS values in Table 36 are drive IOPS. To determine the number of drive IOPS implied by a host 
Storage System Sizing and Performance Planning 
Performance     
99
I/O load, adjust as follows for parity or mirroring operations: 
Parity RAID 5 and 3:  Drive IOPS = Read IOPS + 4*Write IOPS 
Parity RAID 6:  Drive IOPS = Read IOPS + 6*Write IOPS 
Mirrored RAID: Drive IOPS = Read IOPS + 2*Write IOPS  
An example is if there is a four-drive RAID 1/0 (2+2) group, and the I/O mix is 50 percent random reads 
and 50 percent random writes with a total host IOPS of 10,000: 
IOPS = 0.5 * 10,000 + 2 * (0.5 * 10,000) 
IOPS = 15,000 
For bandwidth calculations, when large or sequential I/O is expected to fill LUN stripes, use the following 
approaches, where the write load is increased by a RAID multiplier: 
Parity RAID 5 and 3:  Drive MB/s = Read MB/s + Write MB/s * (1 + (1/ (number of user data drives 
in group))) 
Parity RAID 6: Drive MB/s = Read MB/s + Write MB/s * (1 + (2/ (number of user data drives in 
group))) 
Mirrored RAID:  Drive MB/s = Read MB/s + Write MB/s * 2 
For example, if a RAID 5 group size is 4+1 (four user data drives in group), the read load is 100 MB/s, and 
write load is 50 MB/s: 
Drive MB/s = 100 MB/s + 40 MB/s * (1 + (1/4)) 
Drive MB/s = 150 MB/s 
Calculate the number of drives required 
Make both a performance calculation and storage capacity calculation to determine the number of drives in 
the storage system. 
Performance capacity 
Divide the total IOPS (or bandwidth) by the per-drive IOPS value provided in Table 36 for small-block 
random I/O and Table 37 for large-block random I/O.  The result is the approximate number of drives 
needed to service the proposed I/O load.  If performing random I/O with a predominant I/O size larger than 
16 KB (up to 32 KB), but less than 64 KB, increase the drive count by 20 percent.  Random I/O with a block 
size greater than 64 KB must address bandwidth limits as well.  This is best done with the assistance of an 
EMC professional. 
Storage capacity 
Calculate the number of drives required to meet the storage capacity requirement. Ideally, the number of 
drives needed for the proposed I/O load is equal to the number of drives needed to satisfy the storage 
capacity requirement.  Remember, the formatted capacity of a drive is smaller than its raw capacity.  Use the 
larger number of drives from the performance capacity and storage capacity estimates. 
Furthermore, the vault requires five drives, and it is prudent to add one hot spare drive per 30 drives 
(rounded to the nearest integer) to the drive count.  To simplify the calculation do not include the vault and 
hot spare drives into the performance calculation when calculating the operational performance. 
Storage System Sizing and Performance Planning 
100
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
Total drives 
Total Approximate Drives = RAID Group IOPS / (Hard Drive Type IOPS) + Large Random I/O adjustment 
+ Hot Spares + Vault 
For example, if an application was previously calculated to execute 4,000 IOPS, the I/O is 16 KB random 
requests, and the hard drives specified for the group are 7.2k rpm SATA drives (see Table 36): 
Total Approximate Drives = 4,000 / 80 + 0 + ((4,000 / 80) / 30) + 5 
Total Approximate Drives = 57 
Calculate the number and type of storage systems 
Once the number of drives is estimated, they must be matched to a storage system or set of systems 
supplying performance, capacity, and value to the client. 
Select the storage system whose drive count best fits the client‘s requirement.  Divide the number of drives 
by the maximum drive counts for CX4 from Table 8 on page 40 to determine the number of storage systems 
necessary to service the required drives effectively. 
For best IOPS performance, the optimal Fibre Channel drive count for the storage system is shown in Table 
38.  Use the maximum drive count for the storage system (for example, 480 for a CX4-480) when 
considering entirely SATA drive installations.  Divide the required number of drives by the drive counts in 
Table 38 to determine the type and number of storage systems to deploy.  High-performance storage 
systems require a more complex analysis.  They are not covered in this simple example.  Consult with an 
EMC Professional for information regarding high-performance and high-availability storage system 
configuration. 
Table 37 CX4 optimal drive counts 
CX4-120 
CX4-240 
CX4-480 
CX4-960 
Optimal Fibre Channel drive count  120 
240 
335 
500 
Storage systems  
Storage Systems = Approximate Drives / Storage System Drive Maximum Count  
For example, if a high-performance storage system requires approximately 135 drives: 
Storage Systems = 135 / 240 
Storage Systems = 1 (CLARiiON CX4-240 solution) 
Resolving performance and capacity needs 
The number of drives in a system is determined by the performance and capacity needs. The method 
described previously calculates the minimum number of drives needed to meet performance requirements.  
A separate estimate is required using different drive sizes to calculate the number of drives needed to meet 
capacity requirements. The final number of drives used is determined by interpolating to determine the 
number of drives meeting both performance and capacity requirements.  
Documents you may be interested
Documents you may be interested