Information Technology Reference
In-Depth Information
Unidirectional CHAP is one-way; the source authenticates to the destination, or, in the case
of iSCSI, the iSCSI initiator authenticates to the iSCSI target. Bidirectional CHAP is two-way;
the iSCSI initiator authenticates to the iSCSI target, and vice versa, before communication
is established. Although Fibre Channel SANs are viewed as intrinsically secure because
they are physically isolated from the Ethernet network, and although initiators not zoned to
targets cannot communicate, this is not by dei nition true of iSCSI. With iSCSI, it is possible
(but not recommended) to use the same Ethernet segment as general LAN trafi c, and there
is no intrinsic zoning model. Because the storage and general networking trafi c could share
networking infrastructure, CHAP is an optional mechanism to authenticate the source and
destination of iSCSI trafi c for some additional security. In practice, Fibre Channel and iSCSI
SANs have the same security and same degree of isolation (logical or physical).
IP Security
IPsec is an IETF standard that uses public-key encryption techniques to secure
the iSCSI payloads so that they are not susceptible to man-in-the-middle security attacks.
Like CHAP for authentication, this higher level of optional security is part of the iSCSI stan-
dards because it is possible (but not recommended) to use a general-purpose IP network for
iSCSI transport—and in these cases, not encrypting data exposes a security risk (for example,
a man-in-the-middle attack could determine data on a host it can't authenticate to by simply
reconstructing the data from the iSCSI packets). IPsec is relatively rarely used because it has a
heavy CPU impact on the initiator and the target.
Static/Dynamic Discovery
iSCSI uses a method of discovery where the iSCSI initiator can
query an iSCSI target for the available LUNs. Static discovery involves a manual coni gura-
tion, whereas dynamic discovery issues an iSCSI-standard SendTargets command to one of
the iSCSI targets on the array. This target then reports all the available targets and LUNs to
that particular initiator.
iSCSI Naming Service
The iSCSI Naming Service (iSNS) is analogous to the Domain Name
System (DNS); it's where an iSNS server stores all the available iSCSI targets for a very large
iSCSI deployment. iSNS is rarely used.
Figure 6.14 shows the key iSCSI elements in an example logical diagram. This diagram shows
iSCSI in the broadest sense.
In general, the iSCSI session can be multiple TCP connections, called
Multiple
Connections
Per
Session
. Note that this cannot be done in VMware. An iSCSI initiator and iSCSI target can com-
municate on an iSCSI network portal that can consist of one or more IP addresses. The concept
of network portals is done differently on each array; some arrays always have one IP address
per target port, while some arrays use network portals extensively. The iSCSI initiator logs into
the iSCSI target, creating an iSCSI session. You can have many iSCSI sessions for a single target,
and each session can have multiple TCP connections (Multiple Connections Per Session, which
isn't currently supported by vSphere). There can be varied numbers of iSCSI LUNs behind an
iSCSI target—many or just one. Every array does this differently. We'll discuss the particulars of
the vSphere software iSCSI initiator implementation in detail in the section “Adding a LUN via
iSCSI.”
What about the debate regarding hardware iSCSI initiators (iSCSI HBAs) versus software
iSCSI initiators? Figure 6.15 shows the differences among software iSCSI on generic network
interfaces, network interfaces that do TCP/IP ofl oad, and full iSCSI HBAs. Clearly there are
more things the ESXi host needs to process with software iSCSI initiators, but the additional
CPU is relatively light. Fully saturating several GbE links will use only roughly one core of a
