iSCSI

Introduction

Internet SCSI is one of several block protocols supported by the appliance
for sharing SCSI based storage.

Target Configuration

When using the iSCSI protocol, the target portal refers to the unique
combination of an IP address and TCP port number by which an
initiator can contact a target.

When using the iSCSI protocol, a target portal group is a collection
of target portals. Target portal groups are managed transparently; each network interface
has a corresponding target portal group with that interface's active addresses. Binding
a target to an interface advertises that iSCSI target using the portal
group associated with that interface.

An IQN (iSCSI qualified name) is the unique identifier of a device
in an iSCSI network. iSCSI uses the form iqn.date.authority:uniqueid for IQNs. For
example, the appliance may use the IQN: iqn.1986-03.com.sun:02:c7824a5b-f3ea-6038-c79d-ca443337d92c to identify one of
its iSCSI targets. This name shows that this is an iSCSI device
built by a company registered in March of 1986. The naming authority
is just the DNS name of the company reversed, in this case,
"com.sun". Everything following is a unique ID that Sun uses to identify
the target.

Target Property

Description

Target IQN

The IQN for this target. The IQN can
be manually specified or auto-generated.

Alias

A human-readable nickname for this target.

Authentication mode

One of
None, CHAP, or RADIUS.

CHAP name

If CHAP authentication is used, the CHAP username.

CHAP
secret

If CHAP authentication is used, the CHAP secret.

Network interfaces

The interfaces whose target
portals are used to export this target.

In addition to those properties, the BUI indicates whether a target is
online or offline:

icon

description

Target is online

Target is offline

Clustering Considerations

On clustered platforms, targets which have at least one active interface on
that cluster node will be online. Take care when assigning interfaces
to targets; a target may be configured to use portal groups on
disjoint head nodes. In that situation, the target will be online
on both heads yet will export different LUNs depending on the storage
owned by each head node. As network interfaces migrate between cluster heads as
part of takeover/failback or ownership changes, iSCSI targets will move online and
offline as their respective network interfaces are imported and exported.

Targets which are bound to an IPMP interface will be advertised only
via the addresses of that IPMP group. That target will not
be reachable via that group's test addresses. Targets bound to interfaces
built on top of a LACP aggregation will use the address of
that aggregation. If a LACP aggregation is added to an IPMP
group, a target can no longer use that aggregation's interface, as that
address will become an IPMP test address.

Planning Client Configuration

If you plan on using CHAP authentication, what CHAP credentials does each initiator use?

How many iSCSI disks (LUNs) are required, and how big should they be?

Do the LUNs need to be shared between multiple initiators?

To allow the Appliance to perform CHAP authentication using RADIUS, the following
pieces of information must match:

The Appliance must specify the address of the RADIUS server and a secret to use when communicating with this RADIUS server

The RADIUS server (e.g. in its clients file) must have an entry giving the address of this Appliance and specifying the same secret as above

The RADIUS server (e.g. in its users file) must have an entry giving the CHAP name and matching CHAP secret of each initiator

If the initiator uses its IQN name as its CHAP name (the recommended configuration) then the Appliance does not need a separate Initiator entry for each Initiator box -- the RADIUS server can perform all authentication steps.

If the initiator uses a separate CHAP name, then the Appliance must have an Initiator entry for that initiator that specifies the mapping from IQN name to CHAP name. This Initiator entry does NOT need to specify the CHAP secret for the initiator.

A basic configuration for an iSCSI host is a server with two NICs that are dedicated to iSCSI traffic. The NICs are configured by using IPMP. Additional NICs are provided for non-iSCSI traffic to optimize performance.

Active multipathing can only be achieved by using the Solaris iSCSI MS/T feature, and the failover and redundancy of an IPMP configuration.

*If one NIC fails in an IPMP configuration, IPMP handles the failover. The MPxIO driver does not notice the failure. In a non-IPMP configuration, the MPxIO driver fails and offlines the path.

*If one target port fails in an IPMP configuration, the MPxIO driver notices the failure and provides the failover. In a non-IPMP configuration, the MPxIO driver notices the failure and provides the failover.

For more information about using the Solaris iSCSI MS/T feature with IPMP and multipathing, see SunSolve Infodoc 207607, Understanding an iSCSI MS/T multi-path configuration.