What iSCSI is
The iSCSI protocol is a licensed service on the storage system that enables you to transfer block data to hosts using the SCSI protocol over TCP/IP. The iSCSI protocol standard is defined by RFC 3720 (http://www.ietf.org/).
In an iSCSI network, storage systems are targets that have storage target devices, which are referred to as LUNs (logical units). A host with an iSCSI host bus adapter (HBA), or running iSCSI initiator software, uses the iSCSI protocol to access LUNs on a storage system. The storage system does not have a hardware iSCSI HBA. The iSCSI protocol is implemented over the storage system’s standard gigabit Ethernet interfaces using a software driver.
The connection between the initiator and target uses a standard TCP/IP network. No special network configuration is needed to support iSCSI traffic. The network can be a dedicated TCP/IP network, or it can be your regular public network. The storage system listens for iSCSI connections on TCP port 3260.
What LUNs are
From the storage system, a LUN is a logical representation of a physical unit of storage. It is a collection of, or a part of, physical or virtual disks configured as a single disk. When you create a LUN, it is automatically striped across many physical disks.
Data ONTAP manages LUNs at the block level, so it cannot interpret the file system or the data in a LUN.
From the host, LUNs appear as local disks on the host that you can format and manage to store data.
What nodes are
In an iSCSI network, there are two types of nodes: targets and initiators. Targets are storage systems, and initiators are hosts. Switches, routers, and ports are TCP/IP devices only and are not iSCSI nodes.
How nodes are connected
Supported configurations
Storage systems and hosts can be direct-attached or they can be connected through Ethernet switches. Both direct-attached and switched configurations use Ethernet cable and a TCP/IP network for connectivity.
How iSCSI is implemented on the host
iSCSI can be implemented on the host in one or more of the following ways:
· Initiator software that uses the host’s standard Ethernet interfaces.
· An iSCSI host bus adapter (HBA). An iSCSI HBA appears to the host operating system as a SCSI disk adapter with local disks.
· TCP Offload Engine (TOE) adapter that offloads TCP/IP processing. The iSCSI protocol processing is still performed by host software.
For information about the types of initiators supported, see the Compatibility and Configuration Guide for NetApp’s FCP and iSCSI Products at http://now.netapp.com/NOW/knowledge/docs/san/fcp_iscsi_config/.
How target nodes are connected to the network
The storage system does not use a hardware iSCSI HBA to implement the iSCSI protocol. The iSCSI protocol on the storage system is implemented over the storage system’s standard Ethernet interfaces using software that is integrated into Data ONTAP. iSCSI can be implemented over multiple storage system Ethernet interfaces. An interface used for iSCSI can also transmit traffic for other protocols, such as CIFS or NFS.
Note
For F800 series and FAS900 series models, the e0 interface is a 10/100 interface. Although you can use this interface for iSCSI traffic, NetApp strongly recommends using only gigabit Ethernet (GbE) interfaces for iSCSI traffic.
How nodes are uniquely identified
Every iSCSI node must have a node name. The two formats, or type designators, for iSCSI node names are iqn and eui. The storage system always uses the iqn-type designator. The initiator can use either the iqn-type or eui-type designator.
iqn-type designator
This is a logical name. It is not linked to an IP address; rather, it is based on the following components:
· The type designator itself, iqn, followed by a period (.)
· The date when the naming authority acquired the domain name, followed by a period
· The name of the naming authority, optionally followed by a colon (:)
· A unique device name
Note
Some initiators might provide variations on the above format. For detailed information about the default initiator-supplied node name, see the documentation provided with your iSCSI Host Attach Kit or Support Kit.
The format is:
iqn.yyyy-mm.backward_naming_authority:unique_device_name
yyyy-mm is the month and year in which the naming authority acquired the domain name.
backward_naming_authority is the reverse domain name of the entity responsible for naming this device. An example reverse domain name is com.microsoft.
unique_device_name is a free-format unique name for this device assigned by the naming authority.
The following example shows the iSCSI node name for an initiator that is an application server:
iqn.1987-06.com.initvendor1:123abc
Storage system node name
Each storage system has a default node name based on a reverse domain name and the serial number of the storage system’s non-volatile RAM (NVRAM) card in the following format:
iqn.1992-08.com.netapp:sn.serial_number
The following example shows the default node name for a storage system with the serial number 12345678:
iqn.1992-08.com.netapp:sn.12345678
eui type designator
The format is based on the following components:
· The type designator itself, eui, followed by a period (.)
· Sixteen hexadecimal digits
The format is:
eui.nnnnnnnnnnnnnnnn
How the storage system checks initiator node names
The storage system checks the format of the initiator node name at session login time. If the initiator node name does not comply with storage system node name requirements, the storage system rejects the session.
How node names are used
The host’s node name is used to create initiator groups (igroups). When you create an igroup, you specify a collection of node names of iSCSI initiators. You map a LUN on a storage system to the igroup to grant all the initiators in that group access to that LUN. If a host’s node name is not in an igroup that is mapped to a LUN, that host does not have access to the LUN and the LUNs do not appear as local disks on that host.
Only one host should be allowed to access any given LUN. Clustered hosts can access the same LUNs as long as the clustering software allows only one host to write to any given LUN at a time.
Default port for iSCSI
The iSCSI protocol is configured in Data ONTAP to use TCP port number 3260. Data ONTAP does not support changing the port number for iSCSI. Port number 3260 is registered as part of the iSCSI specification and cannot be used by any other application or service.
What target portal groups are
A target portal group is a set of network portals within an iSCSI node over which an iSCSI session is conducted. In a target, a network portal is identified by its IP address and listening TCP port. For storage systems, each network interface can have one or more IP addresses and therefore one or more network portals. A network interface can be an Ethernet port, virtual local area network (VLAN), or virtual interface (vif).
The assignment of target portals to portal groups is important for two reasons:
· The iSCSI protocol allows only one session between a specific iSCSI initiator port and a single portal group on the target.
· All connections within an iSCSI session must use target portals that belong to the same portal group.
By default, Data ONTAP maps each Ethernet interface on the st
orage system to its own default portal group. You can create new portal groups that contain multiple interfaces.
You can have only one session between an initiator and target using a given portal group. To support some multipath I/O (MPIO) solutions, you need to have separate portal groups for each path. Other initiators, including the Microsoft iSCSI initiator version 2.0, support MPIO to a single target portal group by using different initiator session IDs (ISIDs) with a single initiator node name.
Understanding iSNS
The Internet Storage Name Service (iSNS) is a protocol that enables automated discovery and management of iSCSI devices on a TCP/IP storage network. An iSNS server maintains information about active iSCSI devices on the network, including their IP addresses, iSCSI node names, and portal groups.
You obtain an iSNS server from a third-party vendor. If you have an iSNS server on your network, and it is configured and enabled for use by both the initiator and the storage system, the storage system automatically registers its IP address, node name, and portal groups with the iSNS server when the iSNS service is started. The iSCSI initiator can query the iSNS server to discover the storage system as a target device.
If you do not have an iSNS server on your network, you must manually configure each target to be visible to the host. For information on how to do this, see the appropriate iSCSI host initiator Support Kit or the iSCSI Host Bus Adapter Attach Kit documentation for your specific host.
Currently available iSNS servers support different versions of the iSNS specification. Depending on which iSNS server you are using, you may have to set a configuration parameter in the storage system.
Understanding CHAP authentication
The Challenge Handshake Authentication Protocol (CHAP) enables authenticated communication between iSCSI initiators and targets. When you use CHAP authentication, you define CHAP user names and passwords on both the initiator and the storage system.
During the initial stage of an iSCSI session, the initiator sends a login request to the storage system to begin the session. The login request includes the initiator’s CHAP user name and CHAP algorithm. The storage system responds with a CHAP challenge. The initiator provides a CHAP response. The storage system verifies the response and authenticates the initiator. The CHAP password is used to compute the response.
Communication sessions
During an iSCSI session, the initiator and the target communicate over their standard Ethernet interfaces, unless the host has an iSCSI HBA. The storage system appears as a single iSCSI target node with one iSCSI node name. For storage systems with a MultiStoreTM license enabled, each vFilerTM unit is a target with a different node name.
On the storage system, the interface can be an Ethernet port, virtual network interface (vif), or a virtual LAN (VLAN) interface.
Each interface on the target belongs to its own portal group by default. This enables an initiator port to conduct simultaneous iSCSI sessions on the target, with one session for each portal group. The storage system supports up to 1,024 simultaneous sessions, depending on its memory capacity. To determine whether your host’s initiator software or HBA can have multiple sessions with one storage system, see your host OS or initiator documentation.
You can change the assignment of target portals to portal groups as needed to support multi-connection sessions, multiple sessions, and multipath I/O.
Each session has an Initiator Session ID (ISID), a number that is determined by the initiator.
Options that are automatically enabled
The following options are automatically enabled when the iSCSI service is turned on. Do not change these options.
· volume option create_ucode to On
· cf.takeover.on_panic to On
How vFiler units are used
If you purchased a MultiStore® license and created vFilerTM virtual storage systems, you can enable the iSCSI license for each vFiler to manage LUNs and igroups on a per vFiler basis. For information about vFiler units, see Creating iSCSI LUNs on vFiler units for MultiStore and the sections on iSCSI service on vFiler units or LUNs on vFiler units in the MultiStore Management Guide.
Using iSCSI with clustered storage systems
Clustered storage systems provide high availability because one system in the cluster can take over if its partner ever fails. During cluster failover (CFO), the working storage system assumes the IP addresses of the failed partner and can continue to support iSCSI LUNs.
The two systems in the cluster should have identical networking hardware with equivalent network configurations. The target portal group tags associated with each networking interface must be the same on both systems in the cluster. This ensures that the hosts see the same IP addresses and target portal group tags whether connected to the original storage system or connected to the partner during CFO
