Host Best Practices 
Performance     
21
File-system coalescing 
File-system coalescing can assist in getting high bandwidth from the CLARiiON.  In most sequential-access 
operations, use the maximum contiguous and maximum physical file-system settings (when available) to 
maximize file-system coalescing. This increases the I/O size to the storage system, which helps improve 
bandwidth. 
For example, this technique can be used with backup programs to coalesce 64 KB writes into full-stripe 
writes.  Full stripe writes are very efficient with parity RAID groups when the write cache can be bypassed. 
File-system I/O size 
Coordinating the file-system I/O size with the application and the storage system may result in a positive 
performance effect. 
Minimum I/O size: Ensure the application and file system are not working at cross purposes over minimum 
I/O size.  File systems can be configured for a minimum I/O extent size.  This is the smallest indivisible I/O 
request given to the storage system.  Typical values are 4 KB, 8 KB, 16 KB, or 64 KB.  Applications 
performing I/O at sizes smaller than the file system‘s extent size cause unnecessary data movement or read
-
modify-write activity. 
Note that storage configured as raw partitions, whose request sizes are not limited by a file-system I/O size, 
do not have this constraint. 
Review both the workload‘s applications and operating system‘s file
-system documentation for 
recommendations on resolving the optimal minimum I/O size setting.   
Maximum I/O size: If the goal is to move large amounts of data quickly, then a larger I/O size (64 KB and 
greater) will help.  The storage system is very efficient at coalescing sequential writes in cache to full stripes 
on the RAID groups, as well as pre-reading large sequential reads.  Large I/O sizes are also critical in 
getting good bandwidth from host-based stripes since they will be broken into smaller sizes according to the 
stripe topology. 
File-system fragmentation  
When the percentage of storage capacity utilization is high, file system defragmentation of FLARE LUNs 
can improve performance.  EMC does not recommend that you defragment pool-based LUNs or FAST 
Cache LUNs. 
A fragmented file system decreases storage system throughput by preventing sequential reads and writes.  In 
a fragmented file system the hard drives seek more frequently and over a larger portion of the drive than 
they would if the data were located contiguously on the hard drive.  In general, the longer a file system is in 
use, the more fragmented it becomes.   
Fragmentation noticeably degrades performance when the drive‘s capacity starts to exceed 80 percent.  In 
this case, there is likely to be difficulty finding contiguous drive space for writes without breaking them up 
into smaller fragments.   
It is important to monitor the fragmentation state of the file system.  You should regularly defragment the 
file system hosted on FLARE LUNs with defragmentation tools appropriate to the file system.  
Defragmentation should always be performed during periods of low storage system activity (off-hours). 
Pool-based LUNs do not usually benefit from file system defragmentation the way FLARE LUNs do.  The 
pool‘s allocation algorithms are such that defragmentation of files does not guarantee a
n increase in 
And paste pdf into powerpoint - control software system: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
And paste pdf into powerpoint - control software system: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
Host Best Practices 
22
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
available pool capacity or performance.  Thick LUNs may receive some benefit.  Thin LUNs will receive no 
benefit or only the smallest benefit. 
Thick LUNs pre-allocate their capacity within the pool.  Because of this, there is the potential for some 
benefit in defragmenting them. More heavily fragmented thick LUNs benefit the most.   
It is inadvisable to defragment thin LUNs.  Defragmenting a thin LUN  may reclaim space for the file 
system, but it does not return that capacity to the pool, just to the file system.  The potential performance 
benefit of file consolidation also may not be realized. The defragmented files will likely not result in an 
optimal re-
organization within the pool‘s storage.  The highest pool performance comes when data is 
widely 
distributed across the pool‘s RAID groups.  A thin LUN defragmentation may compact data that was 
previously widely and distributed into a small portion of a smaller number of RAID groups.  This reduces 
overall pool performance. 
You can shrink a host LUN to reclaim the defragmented file system capacity for the pool.  LUN shrinks 
should only be used when severely fragmented pool LUNs have been defragmented.  This is because a LUN 
shrink cannot reduce capacity below 50 percent of the original LUN‘s capa
city.   
In addition, pools implementing the FAST feature or supported by FAST Cache should not be 
defragmented. Defragmentation makes assumptions about the physical layout and physical locality of data 
based on the file system‘s logical locality.  This ass
umption is not correct within a tiered pool or a pool 
supported by a secondary cache.  Depending on the file system‘s allocation granularity the operation of the 
defragmentation may have an adverse effect on performance by changing the previously algorithmically 
selected contents of the tiers or the secondary cache.  A small granularity, for example 4 KB, will result in 
changes that may require re-warming the tiers or cache.  Larger sized granularity is likely to have no effect.    
Defragmentation tools 
EMC does not recommend any defragmentation tool over another.  File-system fragmentation occurs 
independently of the operation of the storage system.  The actions of any defrag tool are simply treated as 
I/O by the storage system. 
Before using any defragmentation tool it is prudent to perform a full backup to ensure the safety of the file 
system.  An effective alternative method to tool-based file-system defragmenting is to perform a file-level 
copy to another LUN, or by executing a backup and restore of the file system. 
File-system alignment 
A file system aligned with RAID group striping has reduced latency and increased throughput.  However, 
only certain types of I/O will see any benefit from alignment.  File-system misalignment adversely affects 
performance in two ways: 
Misalignment causes drive crossings. 
Misalignment makes it hard to stripe-align large uncached writes. 
In a drive crossing, an I/O is broken across two drives.  This is the most common misalignment case.  The 
splitting of the I/O lengthens its duration.  An aligned file system would quickly service the I/O with a 
single drive.  Even if the drive operations are buffered by cache, the effect can be detrimental, as it will slow 
flushing from cache. Random reads, which by nature require drive access, are also affected. They are 
affected directly (they must wait for two drives to return data) and indirectly (the RAID group‘s drives are 
busier than they need to be). 
control software system:C# PDF Page Extract Library: copy, paste, cut PDF pages in C#.net
Ability to copy selected PDF pages and paste into another PDF file. Copy three pages from test1.pdf and paste into test2.pdf.
www.rasteredge.com
control software system:VB.NET PDF Page Extract Library: copy, paste, cut PDF pages in vb.
Ability to copy PDF pages and paste into another PDF file. Support ' Copy three pages from test1.pdf and paste into test2.pdf. Dim
www.rasteredge.com
Host Best Practices 
Performance     
23
The most common example is shown in Figure 2. Intel-based systems are misaligned due to metadata 
written by the BIOS. In an aligned system, the 64 KB write would be serviced by a single drive.    
Metadata 
Disk 3 
64 KB Element Size 
64 KB Write Split into 31.5 KB and 32.5 KB I/Os 
to Disk 
User Data 
Disk 0 
Disk 1 
Disk 2 
Figure 2  
Effect of misalignment with a 63-block metadata area 
Knowing the I/O type and size of the workload is important in understanding the benefits of alignment.  The 
type and size of a data transfer is application-dependent.   
A partition that has been aligned has a noticeable positive effect on response time when there is a high 
percentage of random I/O with block sizes of 16 KB or greater.  Workloads of predominantly 4 KB I/Os 
will see a small advantage from alignment.  Applications such as databases (Oracle, SQL Server, or IBM 
UDB/DB2) supporting multiple block sizes will see a positive performance effect from alignment when the 
larger (8 KB and 16 KB) block size is used.    
With its default 64 KB stripe element size, all I/O larger than 64 KB will involve drive crossings.  To 
minimize the number of crossings, partitions can be aligned on a stripe boundary.  If a specific file system 
or application encourages the use of an aligned address space, and the offset is declared, EMC recommends 
using a host operating system drive utility be used to adjust the partitions.  The Unisphere LUN bind offset 
facility should be used with caution, since it can adversely affect layered application synchronization rates. 
File-system alignment procedure 
Detailed information and instructions for performing file-system alignments for host operating systems can 
be found on Powerlink.  For Microsoft-based file systems refer to the white paper Using diskpar and 
diskpart to Align Partitions on Windows Basic and Dynamic Disks.  For VMware alignment, the Using 
EMC CLARiiON Storage with VMware Infrastructure and vSphere Environments TechBook is a good 
source.  With Linux, align the partition table first using the fdisk utility with instructions provided on the 
man 
page.   
Microsoft-based file-system alignment procedure 
Microsoft Windows Server 2008, partitions are offset by the OS to 1 MB.  This provides good alignment for 
the power-of-two stripe element sizes typically used by the storage system. In addition, be aware that 
Windows Server 2008 defaults to a smaller power-of-two offset for small drives. 
Use the DiskPart  command utility to align Microsoft Windows Server 2003 SP1 or later. To align a basic 
disk, use the align parameter to create a partition: 
This makes the partition start at sector 2048. After aligning the drive, assign a drive letter to the partition 
control software system:C# PDF insert text Library: insert text into PDF content in C#.net
Parameters: Name, Description, Valid Value. value, The char wil be added into PDF page, 0
www.rasteredge.com
control software system:VB.NET PDF insert image library: insert images into PDF in vb.net
project. Import graphic picture, digital photo, signature and logo into PDF document. Add file. Insert images into PDF form field in VB.NET. An
www.rasteredge.com
Host Best Practices 
24
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
before NTFS formatting.  For more information about using the 
DiskPart 
command please refer to Microsoft 
Windows Server 2003 or 2008 documentation. 
You cannot use the align command for dynamic disks; you must use the DiskPart command utility.  
Linux file-system alignment procedure 
The following procedure using 
fdisk
may be used to create a single aligned partition on a second Linux 
file 
sda
or 
sdc
file-system LUN utilizing all the LUN
‘s available capacity.  In this example, this partition 
will be: 
/dev/nativedevicename. 
The procedure is: 
fdisk /dev/nativedevicename # sda and sdc 
n # New partition 
p # Primary 
1 # Partition 1 
<Enter> # 1st cylinder=1 
<Enter> # Default for last cylinder 
# Expert mode 
b # Starting block 
1 # Partition 1 
128 # Stripe element = 128 
w # Write 
Aligning Linux file-system very large LUNs 
To create an aligned partition larger than 2 TB the GUID Partition Table (GPT) drive partitioning scheme 
needs to be used.  GPT is part of the Extensible Firmware Interface (EFI) initiative. GPT provides a more 
flexible mechanism for partitioning drives than the older Master Boot Record (MBR) partitioning scheme.  
By default, a GPT partition is misaligned by 34 blocks.  In Linux, use the parted utility to create and align a 
GPT partition.    
The following procedure describes how to make a partition larger than 2 TB.  In this example, this partition 
will be 
/dev/sdx
. The 
command aligns a 2.35 TB partition to a 1 MB starting offset. 
Following are the Linux commands needed to create a GPT partition: 
# parted /dev/sdb 
GNU Parted 1.6.19 
Using /dev/sdb 
(parted) mklabel gpt 
(parted) p 
Disk geometry for /dev/sdb: 0.000-2461696.000 megabytes 
Disk label type: gpt 
Minor    Start       End     Filesystem  Name                  Flags 
(parted) mkpart primary 1 2461696 
(parted) p 
Disk geometry for /dev/sdb: 0.000-2461696.000 megabytes 
Disk label type: gpt 
Minor    Start       End     Filesystem  Name                  Flags 
         1.000 2461695.983 
(parted) q 
# mkfs.ext3 /dev/sdb1 # Use mkfs to format the file system 
control software system:VB.NET PDF File Split Library: Split, seperate PDF into multiple
Split PDF file into two or multiple files in ASP.NET webpage online. Support to break a large PDF file into smaller files in .NET WinForms.
www.rasteredge.com
control software system:VB.NET PDF Page Insert Library: insert pages into PDF file in vb.
DLLs for Adding Page into PDF Document in VB.NET Class. Add necessary references: RasterEdge.Imaging.Basic.dll. RasterEdge.Imaging.Basic.Codec.dll.
www.rasteredge.com
Host Best Practices 
Availability     
25
Availability 
PowerPath 
Failover is the detection of an I/O failure and the automatic transfer of the I/O to a backup I/O path.  The 
host-resident EMC PowerPath
®
software integrates failover, multiple path I/O capability, automatic load 
balancing, and encryption.  If available on the OS, we recommend PowerPath
whether for a single-attach 
system through a switch (which allows host access to continue during a software update), or in a fully 
redundant system. 
A recommended introduction to PowerPath and its considerations is available in the latest revision of the 
EMC PowerPath Product Guide available on Powerlink. 
Port load balancing 
PowerPath allows the host to connect to a LUN through more than one SP port.  This is known as 
multipathing.  PowerPath optimizes multipathed LUNs with load-balancing algorithms.  It offers several 
load-balancing algorithms.  Port load balancing equalizes the I/O workload over all available channels.  We 
recommend the default algorithm, ClarOpt, which adjusts for number of bytes transferred and for the queue 
depth. 
Hosts connected to CLARiiONs benefit from multipathing.  Direct-attach multipathing requires at least two 
HBAs; SAN multipathing also requires at least two HBAs.  Each HBA needs to be zoned to more than one 
SP port. The advantages of multipathing are: 
Failover from port to port on the same SP, maintaining an even system load and minimizing LUN 
trespassing 
Port load balancing across SP ports and host HBAs 
Higher bandwidth attach from host to storage system (assuming the host has as many HBAs as paths 
used) 
While PowerPath offers load balancing across all available active paths, this comes at some cost: 
Some host CPU resources are used during both normal operations, as well as during failover. 
Every active and passive path from the host requires an initiator record; there are a finite number of 
initiators per system. 
Active paths increase time to fail over in some situations. (PowerPath tries several paths before 
trespassing a LUN from one SP to the other.) 
Because of these factors, active paths should be limited, via zoning, to two storage system ports per HBA 
for each storage system SP to which the host is attached. The exception is in environments where bursts of 
I/O from other hosts sharing the storage system ports are unpredictable and severe. In this case, four storage 
system ports per HBA should be used. 
The EMC PowerPath Version 5.5 Product Guide available on Powerlink provides additional details on 
PowerPath configuration and usage. 
Other multipath I/O applications (MPIO) 
Applications other than PowerPath may be used to perform the MPIO function.  These applications perform 
similarly to PowerPath, although they may not have the all the features or as close integration with the 
CLARiiON of PowerPath. 
control software system:C# PDF insert image Library: insert images into PDF in C#.net, ASP
Import graphic picture, digital photo, signature and logo into PDF document. Merge several images into PDF. Insert images into PDF form field.
www.rasteredge.com
control software system:C# PDF File Split Library: Split, seperate PDF into multiple files
Divide PDF File into Two Using C#. This is an C# example of splitting a PDF to two new PDF files. Split PDF Document into Multiple PDF Files in C#.
www.rasteredge.com
Host Best Practices 
26
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
Microsoft Multi-Path I/O  
Microsoft Multi-Path I/O (MPIO) as implemented by MS Windows Server 2008 provides a similar, but 
more limited, multipathing capability than PowerPath.  Features found in MPIO include failover, failback, 
Round Robin Pathing, weighted Pathing, and I/O Queue Depth management.  Review your Microsoft 
Server OS‘s documentation for information on available MPIO features and their implementation.
Linux MPIO  
Linux MPIO is implemented by Device Mapper ( ).  It provides a similar, but more limited, multipathing 
capability than PowerPath.  The MPIO features found in Device Mapper are dependent on the Linux release 
and the revision.  Review the Native Multipath Failover Based on DM-MPIO for v2.6.x Linux Kernel and 
EMC Storage Arrays Configuration Guide available on Powerlink for details and assistance in configuring 
Device Mapper. 
ALUA 
Asymmetric Logical Unit Access (ALUA) can reduce the effect of some front- and back-end failures to the 
host.  It provides path management by permitting I/O to stream to either or both CLARiiON storage 
processors without trespassing.  It follows the SCSI SPC-3 standard for I/O routing.  The white paper EMC 
CLARiiON Asymmetric Active/Active Feature available on Powerlink provides an in-depth discussion of 
ALUA features and benefits.  
Host considerations 
PowerPath versions 5.1 and later are ALUA-compliant releases.  Ensure usage of PowerPath version 5.1 or 
later, and reference 
PowerPath
on page 25 for host compliance. 
PowerPath load balances across optimized paths.  It only uses non-optimized paths if all the original 
optimized paths have failed.  For example when an optimized path to the original owning SP fails, it sends 
I/O via the non-optimal path to the peer SP.  If path or storage processor failures occur, PowerPath initiates 
a trespass to change LUN ownership.  That is, the non-optimized path becomes the optimized path, and the 
optimized path becomes the non-optimized paths.   
Not all multipathing applications or revisions are ALUA compliant.  Verify that your revision of MPIO or 
other native host-based failover application can interoperate with ALUA.  
When configuring PowerPath on hosts that can use ALUA, use Failover Mode 4 .  This configures the 
CLARiiON for asymmetric Active/Active operation.  This has the advantage of allowing I/O to be sent to a 
LUN regardless of LUN ownership.  Details on the separate failover modes 1 through 4 can be found  in the 
EMC CLARiiON Asymmetric Active/Active Feature  
A Detailed Review white paper, available on 
Powerlink. 
OS considerations 
To take advantage of ALUA features, host software needs to be ALUA-compliant.  Several operating 
systems support native failover with Active/Passive (A/P) controllers.  
The next table shows the current ALUA status of some common operating systems. 
Host Best Practices 
Availability     
27
Table 1  ALUA and Active/Passive Failover compliant OSs 
Operating 
system 
PowerPath with 
ALUA 
Native with 
ALUA 
PowerPath with 
A/P 
Native with 
A/P 
MS Windows 
Server 2008 
Yes 
Yes 
Yes 
No 
W2K3 
PP 5.1 and later 
No 
Yes 
No 
Win2K 
PP 5.1 and later 
No 
Yes 
No 
HP-UX 11i v1 and 
v2 
PP 5.1.1 and later 
No 
Yes 
Yes (LVM) 
HP-UX 11i v3
PP 5.1.1 and later
Yes
No
No
Solaris 9/10 
PP 5.1 and later 
Yes 
Yes 
Yes 
Linux  (RH and 
SuSE) 
Yes 
SLES 10 SP1 
RHEL 4.6, 5.4 
Yes 
Yes 
AIX 
No 
No 
Yes 
AIX 5.3 and 
higher 
VMware ESX 3.x 
No 
No 
No 
Yes 
VMware ESX 4.x
PP/VE 5.4 and later  Yes 
PP/VE 5.4 and 
later 
Yes 
PowerPath with ALUA:  ALUA features are provided when the specified PowerPath release is used with 
the noted operating system.  
Native with ALUA:  ALUA features are provided when using the noted operating system alone. 
(PowerPath is not required.) 
PowerPath with A/P:  Standard Active/Passive failover (not ALUA) is provided by PowerPath with the 
noted operating system. (PowerPath issues trespass commands to enable alternate paths by changing SP 
LUN ownership.) 
Native with A/P:  Standard Active/Passive failover (not ALUA) is provided when using the noted operating 
system alone.  (OS issues trespass commands to enable alternate paths.) 
Performance considerations 
The optimized path is the normal operation path.  ALUA has no effect on optimized path performance. 
Performance is adversely affected on the non-optimized path.   
Host I/O requests received over non-optimized paths are received by the storage processor not owning the 
destination LUN.  These requests are then forwarded to the peer storage processor owning the LUN.  This 
storage processor executes the I/O as though the request had been received directly.  When the I/O 
completes, data or acknowledgements are forwarded back through the peer to be transmitted to the host.   
The redirection, from storage processor to peer storage processor and back, increases I/O response time.  
The duration of the delay is dependent on the overall storage system, storage processor workloads, and the 
size of the I/O.  Expect a 10-20 percent decrease in maximum IOPS, and up to a 50 percent decrease in 
bandwidth with non-optimum path usage. 
Monitoring ALUA performance 
A number of metrics have been created to describe requests arriving over optimized versus non-optimized 
paths.  This path usage can be monitored through Unisphere Analyzer.  In addition, metrics exist for total 
Host Best Practices 
28
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
I/O over all paths.  These metrics describe the utilization of paths and the differences in performance.  
Information on how to use Unisphere Analyzer can be found in the EMC Navisphere Analyzer 
Administrator’s Guide
, available on Powerlink.   
Queuing, concurrency, queue-full (QFULL) 
A high degree of request concurrency is usually desirable, and results in good resource utilization.  
However, if a storage system‘s queues become full, it will respond with a 
queue-full (QFULL) flow control 
command. The CX4 front-end port drivers return a QFULL status command under two conditions:   
The practical maximum number of concurrent host requests at the port is above 1600 (port queue limit). 
The total number of requests for a given LUN is (14 * (the number of data drives in the LUN) ) + 32 
The host response to a QFULL is HBA-dependent, but it typically results in a suspension of activity for 
more than one second.  Though rare, this can have serious consequences on throughput if this happens 
repeatedly. 
The best practices 1600 port queue limit allows for ample burst margin.  In most installations, the maximum 
load can be determined by summing the possible loads for each HBA accessing the port and adjusting the 
HBA LUN settings appropriately.   (Some operating system drivers permit limiting the HBA concurrency 
on a global level regardless of the individual LUN settings.)  In complex systems that are comprised of 
many hosts, HBAs, LUNs, and paths, it may be difficult to compute the worst-case load scenario (which 
may never occur in production anyway).  In this case, use the default settings on the HBA and if QFULL is 
suspected, use Unisphere Analyzer (release 30 or later) to determine if the storage system‘s front
-end port 
queues are full by following the steps described below. Information on how to use Unisphere Analyzer can 
be found in the Unisphere online help.   
HBA queue depth settings usually eliminate the possibility of LUN generated QFULL.  For instance, a 
RAID 5 4+1 device would require 88 parallel requests ((14*4) + 32) before the port would issue QFULL.  If 
the HBA queue-depth setting is 32, then the limit will never be reached.  A common exception is for RAID 
1 (or RAID 1/0 (1+1)).  For example, if  the HBA queue-depth default setting was altered to a larger value 
(such as 64) to support greater concurrency for large metaLUNs owned by the same host, the RAID 1 
device could reach queue-full because its limit is 46 requests(1*14)+32). 
QFULL is never generated as a result of a drive‘s queue
-depth. 
Port statistics are collected for Unisphere Analyzer; this data includes several useful statistics for each 
individual port on the SP: 
Port queue-full 
a counter has been added showing the number of QFULL signals issued due to port 
queue overflow  
Per-port bandwidth and IOPS 
Usage 
Consider all hosts connected to the storage system, and which LUNs they access.  If necessary, set HBA 
throttles to limit concurrent requests to each LUN.  Depending on the operating system, it may be possible 
to globally limit the total outstanding requests per HBA or per target. Set the HBA throttles of the hosts 
sharing a port so the total cannot exceed the port queue limit.  Remember that multipathing to one LUN via 
multiple ports on the same SP may lead to exceeding the port queue limit. 
Host Best Practices 
Availability     
29
If high concurrency is suspected and performance problems occur, check port statistics reported by 
Unisphere Analyzer for queue-fulls, and lower the HBA throttles if appropriate. 
Storage network adapters and HBAs 
Hosts use Fibre Channel HBAs to attach to Fibre Channel storage networks.  A network interface card 
(NIC), iSCSI HBAs, and TCP/IP Offload Engines (TOE) with iSCSI drivers connect a host to an Ethernet 
network for iSCSI storage network support.  HBAs, NICs, and TOEs share the host‘s I/O bus bandwidth.
Host bus 
Ensure the network adapter‘s full bandwidth is supported by the host‘s I/O bus hardware.  (The host‘s I/O 
bus is sometimes called the peripheral bus
.) Knowing the number, distribution, and speed of the host‘s 
buses is important to avoid bottlenecks within the host.    
Entry-level and legacy hosts may have less internal I/O bus bandwidth than their network adapters or HBAs.  
For this reason it is important to verify that your host can handle the bandwidth of the network interfaces 
when using these protocols: Fibre Channel networks that are faster than 4 Gb/s; 10 Gb/s Ethernet; and 10 
Gb/s Fibre Channel over Ethernet (FCoE).   In addition, when more than one adapter is present on a host I/O 
bus, remember that these adapters share the available bus bandwidth, and it is possible for the summed 
bandwidth requirement of the adapters to exceed the host‘s available bus bandwidth.  
The ratio of network adapter ports to buses needs to be known.  A host may have more than one internal 
bus.  The distribution of bus slots accepting network adapters to buses is not always obvious.  Review the 
number of network adapters, and the number of ports per network adapter that are being attached to each of 
a host‘s individual buses.  Ensure that network adapters are connect
ed to fast (>66 MHz) and wide (64-bit) 
PCI, PCI-X, and four-lane (x4) or greater PCI Express (PCIe) 1.1 or 2.0 host buses.  In all cases, the host 
I/O bus bandwidth needs to be greater than the summed maximum bandwidth of the network adapters to 
avoid a bottleneck. 
HBAs 
High availability requires two HBA connections to provide dual paths to the storage network or if directly 
connected, to the storage system. 
It is a best practice to have redundant HBAs.  Either multiport (dual or quad) or multiple single-port HBAs 
may be used.  Using more than one single-port HBA enables port- and path-failure isolation, and may 
provide performance benefits.  Using a multiport HBA provides a component cost savings and efficient port 
management that may provide a performance advantage.  For example, multiport HBAs are useful for hosts 
with few available I/O bus slots.  The liability is a multiport HBA presents a single point of failure for 
several ports.  Otherwise, with a single-ported HBA, a failure would affect only one port.  HBAs should also 
be placed on separate host buses for performance and availability.  Note this may not be possible on smaller 
hosts that have a single bus or a limited number of bus slots. In this case, multiport HBAs are the only 
option. 
Always use an 
HBA rated for or exceeding the bandwidth of the storage network‘s maximum bandwidth.  
Ensure that legacy 1 Gb/s or 2 Gb/s HBAs are not used for connections to 4 Gb/s or higher SANs.  FC 
SANs reduce the speed of the network path to the HBA‘s lower speed ei
ther as far as the first connected 
switch, or to the storage system‘s front
-end port when directly connected.  This may bottleneck the overall 
network when bandwidth is intended to be maximized. 
Host Best Practices 
30
EMC CLARiiON Best Practices for Performance and Availability: Release 30.0 Firmware Update Applied Best Practices  
Finally, using the current HBA firmware and driver from the manufacturer generally has a positive effect on 
performance and availability.  The CLARiiON Procedure Generator (installation available through 
Powerlink) provides instructions and the configuration settings for HBAs specific to your storage system. 
Network interface cards (NIC), TCP/IP offload engines (TOE), and iSCSI host bus adapters (HBA) 
Three host devices connect hosts to iSCSI SANs: NICs, TOEs, and iSCSI HBAs.  The differences in the 
devices include cost, host CPU utilization, and features (such as security).  The same server cannot use both 
NICs and HBAs for paths to iSCSI storage systems. 
NICs are the typical way of connecting a host to an Ethernet network.  They are supported by software 
iSCSI initiators on the host.   
Ethernet networks will auto-negotiate down to the lowest common device speed.  Using a lower-rated NIC 
may bottleneck the storage network‘s bandwidth.  When possible, use a NIC rated for or exceeding the 
bandwidth of the available Ethernet network.  Do not use legacy 10 Mb/s or 100 Mb/s NICs for iSCSI SAN 
connections to 1 Gb/s or higher Ethernet networks.   
A TOE is a faster type of NIC.  A TOE has on-board processors to handle TCP packet segmentation, 
checksum calculations, and optionally IPSec (security) offload from the host CPU on to themselves.  This 
allows the host CPU(s) to be used exclusively for application processing. 
In general, iSCSI HBAs are the most scalable interface.  On iSCSI HBAs the TCP/IP and iSCSI processing 
is offloaded to the HBA.  This reduces host CPU utilization.  An iSCSI HBA also allows booting off an 
iSCSI target.  This is an important consideration when considering diskless host booting.  HBAs also 
typically provide for additional services such as security. 
The decision to use an iSCSI HBA versus a TOE, versus a NIC is dependent on the percentage CPU 
utilization of the host when it is processing workload(s).  On small hosts, and hosts with high CPU 
utilizations, a TOE or iSCSI HBA can lower the host‘s CPU utilization.  However, using an HBA or TOE 
may increase workload response time.  In addition, an iSCSI HBA or TOE costs more than a conventional 
NIC.  On large hosts or hosts not affected by high CPU utilization, we recommend a conventional NIC.  
Note that to work on an iSCSI SAN, the NIC must support the iSCSI protocol on the host.  Check with the 
NIC‘s manufacturer for the appropriate driver support.
Redundant NICs, iSCSI HBAs, and TOEs should be used for availability.  NICs may be either single or 
multiported.  A host with a multiported NIC or more than one NIC is called a multihomed host.  Typically, 
each NIC or NIC port is configured to be on a separate subnetIdeally, when more than one NIC is 
provisioned, they should also be placed on separate host buses.  Note this may not be possible on smaller 
hosts having a single bus or a limited number of bus slots, or when the on-board host NIC is used. 
All NICs do not have the same level of performance.  This is particularly true of host on-board (mainboard) 
NICs, 10 Gb/s NICs, and 10 Gb/s HBAs.  For the most up-to-date compatibility information, consult the 
EMC Support Matri(ESM), available through E-Lab Interoperability Navigator (ELN) at: 
http://elabnavigator.EMC.com. 
Finally, using the current iSCSI initiator, NIC, TOE, or iSCSI HBA firmware and driver from the 
manufacturer generally has a positive effect on performance and availability.  You can use the web page at 
http://corpusweb130.corp.emc.com/upd_prod_CX4/
to create custom documentation that provides 
instructions and configuration settings for NICs and TOEs in your storage system configuration.  
Documents you may be interested
Documents you may be interested