Optimizing-QoS-vSphere_final

QoS Best Practice 5: Determine
Performance of Native versus

Testing in Intel’s performance labs shows
some native software initiators out-
performhardware-ofoadedfunctions.
For example, hardware-based initiators
thatarefoundoniSCSIofoadsorHost
Bus Adapters (HBAs) might not have
equivalentorsimilarperformancebenets
on the most current server platforms
as compared to those they had on older
platforms.Insomecases,CPUutilization
mightbelowerusinghardwareofoads,
buttheoverallnumberofI/Ooperations
persecondisalsosignicantlylower.
With the power and speed of today’s
server platforms and 10GbE network
connections,ofoadprocessorscan
easily become overwhelmed, requiring
owcontrolstobeputinplacetoreduce
the amount of data submitted to the
ofoadprocessor.Suchowcontrolscan
reducethebenetsofofoadprocessors
signicantly.
VMwarehasmadesignicantperformance
improvements for iSCSI storage, including
iSCSI boot support on Intel® Ethernet
adapters. Using software initiators instead
ofanofoadallowsITorganizations
to take advantage of a combination of
new in-guest virtualization-optimized
iSCSI drivers and VMkernel-level storage
stack optimizations. These factors can
dramaticallyimproveperformanceforI/O-
intensive applications such as databases
and messaging.
Several features in vSphere 4.1 also
provide prioritization for network and
storageI/Othatcannotbeusedifthe
trafcisofoadedtoanHBA.The
tradeoffs associated with not using
software-controlled initiators may be
prohibitive on newer platforms. Having
to use a separate management and
monitoringtooltocongurethehardware
canalsoaddsignicantcomplexityand
cost to the solution.
Todeterminewhetheranofoadis
needed, run workloads that correspond
to both maximum throughput and
real-worldscenariosusingtheofoad
enabled, and compare the performance
results to similar cases when the the
OS-native software initiators are used
insteadofofoadingthefunction.It
is also necessary to check VMware’s
documentation to determine the
compatibility of individual vSphere 4.1
functionsandfeatureswithofoad.See
the ESXCongurationGuide
9
and the ESXi
CongurationGuide.
10
ESX can use different types of adapters to
provide iSCSI connections. Two examples
arenativesoftware-basediSCSIadapter/
initiators and dependent hardware
iSCSI adapters, as shown in Figure 7 and
described below.

Adapter/Initiators
A software iSCSI adapter is a VMware
code built into the VMkernel. It allows
a host to connect to the iSCSI storage
device through standard network
adapters. The software iSCSI adapter
handles iSCSI processing while
communicating with the network adapter.
The software iSCSI adapter allows the use
of iSCSI technology without the need to
purchase specialized hardware. The host
needs only a standard network adapter
for network connectivity. iSCSI and
network processing is done primarily by a
hostCPUbutcanbeassistedbystateless
ofoadsintheadapter/controller.
Native software-based iSCSI
adapter/initiatorsanddependenthardware
iSCSI adapters are examples of adapters ESX
uses to provide iSCSI connections.
ESX/ESXi
virtual
machine
virtual disk
virtual disk
hardware
iSCSI
initiator
(HBA)
VMFS
LUN1 LUN2 LUN5
VMware virtualization layer
software iSCSI initiator
SCSI
controller
virtual
machine
SCSI
controller
ethernet
NIC
LAN
LAN
.vmdk RDM
Load-basedteamingcanhelpbalancethetrafficloadbetweenphysicalserveradapters.
Unbalanced Traffic
vNetwork
Distributed
Switch
VM1 40% VM2 10%
VM3 40%
VM1 40%
VM3 40%
VM2 10%
VM3 40%
Load-based Teaming (LBT)
APP
OS
APP
OS
APP
OS
0%
0%
VM140%
VM2
VM2
10
10
vNetwork
Distributed
Switch
APP
OS
APP
OS
APP
OS
0%
0
0
%
%
7
