IBM N Series, Hardware Manual

Page: 296 / 368

276
IBM System Storage N series Hardware Guide
19.2.2 Native multipathing solution
Native multipathing solutions are packaged as part of the operating system. As of the time of
this writing, Windows, ESX, Linux, HP-UX, Solaris, and AIX provide native multipathing
solutions. Native multipathing solutions have the following advantages:
򐂰 Native multipathing solutions are available for no extra fee. Native multipathing reduces
capital expense (can limit the number of redundant servers) and operating expense.
򐂰 The availability of multipath support in the server operating systems allows IT installations
to adopt a more sensible server-led strategy. This strategy is independent of the storage
array vendors. It does not limit you to a single storage array, and so provides freedom of
choice and flexibility when a storage vendor is selected.
򐂰 Native multipathing provides better interoperability among various vendor storage devices
that connect to the same servers. One driver stack and one set of HBAs can communicate
with various heterogeneous storage devices simultaneously.
With the advent of SCSI concepts, such as asymmetric logical unit access (ALUA), native
multipathing solutions improved. For example, Microsoft provided native Fibre Channel
multipathing support only after ALUA became available for Windows.
19.2.3 Asymmetric Logical Unit Access
ALUA is an industry-standard protocol that enables the communication of storage paths and
path characteristics between an initiator port and a target port. This communication occurs
when the access characteristics of one port might differ from those of another port. A logical
unit can be accessed from more than one target port. One target port might provide full
performance access to a logical unit. Another target port, particularly on a different physical
controller, might provide lower performance access or might support a subset of the available
SCSI commands to the same logical unit.
Before inclusion of ALUA in the SCSI standards, multipath providers had to use
vendor-specific SCSI commands to figure out the access characteristics of a target port. With
the standardization of ALUA, the multipath vendor can use standard SCSI commands to
determine the access characteristics. ALUA was implemented in Data ONTAP 7.2.
iSCSI in N series controllers have no secondary path. Because link failover operates
differently from Fibre Channel, ALUA is not supported on iSCSI connections.
Certain hosts, such as Windows, Solaris, and AIX require the system to rediscover their disks
for ALUA to be enabled. Therefore, reboot the system after the change is made.
19.2.4 Why ALUA?
Traditionally, IBM wrote a plug-in for each SCSI multipathing stack with which it interacts.
These plug-ins used vendor-unique SCSI commands to identify a path as Primary or
Secondary. By supporting ALUA with SCSI multipathing stacks that also support ALUA,
support is obtained without writing any new code on the host side.
Data ONTAP implements the implicit ALUA style, not the explicit format. Implicit ALUA makes
the target device responsible for all the changes to the target port group states. With implicit
access, the device controller manages the states of path connections. In this case, the
standard understands that there might be performance differences between the paths to a
LUN. Therefore, it includes messages that are specific to a path that changes its
characteristics, such as changes during failover and giveback.