NetApp iSCSI Management using Open Interfaces

iSCSI, an industry standard storage protocol defined and maintained by the Internet Engineering Task Force, enables the consolidation, scalability, and management advantages of a storage area network (SAN) without the unfamiliarity, complexity, and expense of traditional SAN interconnects. Also known as Internet SCSI, iSCSI encapsulates SCSI block storage commands into Ethernet packets for transport over IP networks, enabling companies to leverage standard, familiar Ethernet networking infrastructures to create affordable SANs.

In its simplest form, an iSCSI-based SAN (IP SAN) solution consists of servers equipped with either standard Gigabit Ethernet network interface cards and iSCSI "initiator" software or iSCSI host bus adapter cards and driver software. Cards are connected via an Ethernet switch to a native iSCSI storage system using standard Ethernet cables. The networked storage pool appears to each of the servers to be dedicated local disk storage.

The iSCSI protocol was designed with the appropriate security options to enable the creation of SANs over a wide range of network topologies—from private IP-based subnets to data center or departmental local area networks (LANs) and wide area networks (WANs).

iSCSI-based SAN solutions are an excellent choice for storage consolidation in low-cost and Intel® architecture server environments and are particularly attractive in departmental, regional, or remote data centers where Fibre Channel solutions have not historically offered a cost-effective option. iSCSI also provides highly affordable secondary storage or data protection solutions for corporate data centers.

An iSCSI SAN may be the perfect choice for companies interested in making the move from direct-attached to networked storage. Using the same block-level SCSI commands as traditional server-attached storage, iSCSI storage networks are fully compatible with existing server software such as file systems, databases, and applications. Similarly, since iSCSI runs on ubiquitous and familiar IP networks, there is no need to deploy a new networking infrastructure or retrain staff to realize the benefits of a SAN.

Unlike direct-attached storage, iSCSI storage solutions enable you to share storage resources across servers, easily expand storage capacity without taking critical applications offline, and consolidate your data protection processes and operations for improved data availability at significant administrative cost savings.

Current deployments of iSCSI span a broad range of industries and IT environments.

Figure 1: iSCSI Deployment Scenario

The benefits of using iSCSI based storage solutions are:

• Significant cost savings. iSCSI SAN storage solutions leverage the volume economics, scalability, and simplicity of standard Ethernet networking.
• Investment protection. iSCSI enables you to leverage your existing Ethernet networking investment and expertise to deploy either departmental SANs that complement your existing Fibre Channel data center SAN or "green field" SANs within a distributed IT environment.
• Proven technology. iSCSI brings together two of the most ubiquitous and well-understood technologies in the IT industry—SCSI storage and IP networks.

In an iSCSI network, there are two types of nodes: targets and initiators. Targets are NetApp systems, and initiators are hosts. NetApp systems have storage devices, which are referred to as logical units of storage (LUNs). From the host, iSCSI LUNs appear as local disks on the host that you can format and manage to store data, using the iSCSI protocol.

Switches, routers, and ports are TCP/IP devices only and are not iSCSI nodes. Hosts can be direct-attached or they can be connected via TCP/IP switches. Both direct-attached and switched configurations use Ethernet cable and a TCP/IP network for connectivity.

iSCSI is implemented on the host in the following ways:

• Initiator software that uses the host's standard Ethernet interfaces.
• iSCSI Host Bus Adapter (HBA)
• TCP Offload Engine (TOE) HBA, which offloads TCP/IP processing. iSCSI protocol processing is still performed on the host.

During an iSCSI session, the initiator and the target communicate over their standard Ethernet interfaces, unless the host has a vendor-supplied HBA. The NetApp system appears as a single iSCSI target node with one iSCSI node name. The NetApp system supports one TCP connection per iSCSI session.

An iSCSI session can be conducted over a NetApp system virtual network interface (vif). In Data ONTAP 6.5 or later, an iSCSI session can be conducted over a virtual LAN (VLAN) interface.

The iSCSI software adapter maps each Ethernet interface on the target to a single portal group. In this way, an initiator port can conduct simultaneous iSCSI sessions on the target, with one session for each portal group. The iswt driver allows 1024 simultaneous sessions, depending on the memory capacity of the NetApp system. To determine whether your host's initiator software can take advantage of this functionality, see your host documentation.

Each session has an Initiator Session ID (ISID), a number that is determined by the initiator.

The iSCSI protocol on the NetApp system is implemented over the standard Ethernet interfaces using a software driver that is integrated into Data ONTAP. This software is a virtual adapter, called the iSCSI Software Target (iswt) that is pre-installed on the NetApp system. 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.

Data ONTAP provides two logical iswt adapters: iswta and iswtb. The iswta adapter controls all iSCSI traffic for the NetApp system. If the NetApp system is in a cluster, the iswtb adapter is dedicated to iSCSI traffic for the partner NetApp system. If a failover occurs and the NetApp system is operating in takeover mode, the iswtb adapter becomes active.

iSCSI can be implemented over multiple NetApp system Ethernet interfaces. You use the iswt interface command to specify which interfaces are used for iSCSI traffic. An interface used for iSCSI can also transmit traffic for other protocols, such as CIFS or NFS.

Every iSCSI node must have a node name. The two formats, or type designators, for iSCSI node names are iqn and eui. The NetApp system must use the iqn-type designator. The initiator can use either the iqn-type or eui-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.netapp.

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

Each NetApp system has a default node name based on the NetApp reverse domain name and the serial number of the NetApp system's NVRAM card in the following format:

iqn.1992-08.com.netapp:sn.serial_number.

The following example shows the default node name for a NetApp system with the serial number 12345678:

iqn.1992-08.com.netapp:sn.12345678

The format is based on the following components:

• The type designator itself, eui, followed by a period (.)
• Sixteen hexadecimal digits

The format is:

eui.nnnnnnnnnnnnnnn

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 NetApp 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.

The NetApp system checks the format of the initiator node name at session login time. If the initiator node name does not comply with NetApp system node name requirements, the NetApp system rejects the session.

The ONTAPI interface is a set of foundational APIs for managing NetApp Storage Systems. This is a proprietary interface developed by NetApp for advance management of NetApp Storage Systems. ONTAPI includes APIs for qtrees, quotas, volumes, LUNs, Snapshots™, SnapMirror®, vFilers™, and numerous other features.

ONTAPI interfaces use XML as a format and may be configured to use either HTTP or DCE/RPC as the transport mechanism. HTTP is important when managing devices which may be outside of the corporate firewall, and locked down so that only port 80 is available, and is the default transport configuration. Security for HTTP can be provided by using SSL.

ONTAPI is implemented as a small set of primitives that marshal and un-marshal arguments onto and from the wire, using XML as the description language. At present, bindings for C/C++, Perl, and Java are provided. Development of bindings for other languages will be driven primarily by developer demand.

SNMP (Simple Network Management Protocol) is a well-known standard for network management. NetApp storage systems support SNMP V1. NetApp only supports monitoring using SNMP which means that SNMP SET operations are not permitted.

If SNMP is enabled in Data ONTAP, SNMP managers can query your storage system's SNMP agent for information (specified in your storage system's MIBs or the MIB-II specification). In response, the SNMP agent gathers information and forwards it to the SNMP managers using the SNMP protocol. The SNMP agent also generates trap notifications whenever specific events occur and sends these traps to the SNMP managers. The SNMP managers can then carry out actions based on information received in the trap notifications.

The following table provides details on how to verify / enable iSCSI licenses on the NetApp Storage.

The following table provides details on how to verify / start / stop the iSCSI service on the NetApp Storage.

The following table provides details on how to view / change the target node name of the NetApp Storage

Changing the storage system’s node name while iSCSI sessions are in progress does not disrupt the existing sessions. However, when you change the storage system’s node name, you must reconfigure the initiator so that it recognizes the new target node name. If you do not reconfigure the initiator, subsequent initiator attempts to log in to the target will fail.

Node name rules: If you change the storage system’s target node name, be sure the new name follows all of these rules:

The target alias is an optional human-readable name for the iSCSI target. For example, if the target node name was iqn.1992-08.com.netapp:sn.33604646, you might want an alias such as Filer_1. The alias is a text string with a maximum of 128 characters. The alias is intended to be displayed by an initiator’s user interface to make it easier for someone to identify the desired target in a list of targets. Depending on the initiator, the alias may or may not be displayed in the initiator’s user interface.

You can change the target alias or clear the alias at any time without disrupting existing sessions. The new alias will be sent to the initiators the next time they log in to the target.

The following table provides details on how to view / add / delete the target alias for the NetApp Storage:

An iSNS server uses the Internet Storage Name Service (iSNS) protocol to maintain information about active iSCSI devices on the network, including their IP addresses, iSCSI node names, and portal groups. The iSNS protocol enables automated discovery and management of iSCSI devices on an IP storage network. An iSCSI initiator can query the iSNS server to discover iSCSI target devices

The storage system automatically registers its IP address, node name, and portal groups with the iSNS server when the iSCSI service is started and iSNS is enabled. After iSNS is initially configured, Data ONTAP automatically updates the iSNS server any time the storage system’s configuration settings change. There can be a delay of a few minutes between the time of the configuration change and the update being sent; you can use the Open Interfaces to send an update immediately.

Note: NetApp does not supply or resell iSNS servers. You obtain these servers from a vendor supported by NetApp. Be sure to check the NetApp iSCSI Support Matrix to see which iSNS servers are currently supported.

The following table provides details on how to use Open Interfaces to configure iSNS on NetApp storage systems:

The specification for the iSNS service is still in draft form. Some draft versions are different enough to prevent the storage system from registering with the iSNS server. The iSNS servers and storage systems cannot negotiate the draft level being used, because the protocol does not provide version information to the draft level.

By default, Data ONTAP versions prior to 7.1 used iSNS draft 18. In Data ONTAP 7.1, the default iSNS version is draft 22.

The following table provides details on how to view / change the iSNS version information on NetApp Storage systems.

The NetApp 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 systems' Ethernet interfaces. You can control which network interfaces are used for iSCSI communication. For example, you can enable iSCSI communication over specific gigabit Ethernet (GbE) interfaces. By default, the iSCSI service is enabled on all Ethernet interfaces after enabling the license.

The following table provides details on how to manage Ethernet interfaces on NetApp storage:

During the initial stage of an iSCSI session, the initiator sends a login request to the storage system to begin an iSCSI session. The storage system permits or denies the login request according to one of the following authentication methods:

You can define a list of initiators and their authentication methods. You can also define a default authentication method for initiators that are not on this list. If you have not specified a list of initiators and authentication methods, the default method is none—any initiator can access the storage system without authentication.

The following guidelines apply to CHAP authentication:

The following table provides the details of various initiator operations on NetApp storage systems:

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:

By default, Data ONTAP maps each Ethernet interface on the storage 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.

The following table provides details on how to manage target portal groups on NetApp storage systems:

Initiator groups (igroups) are tables of host identifiers (FCP WWPNs or iSCSI node names) that are used to control access to LUNs. Typically, you want all of the host’s HBAs or software initiators to have access to a LUN. If you are using multipathing software or have clustered hosts, each HBA or software initiator of each clustered host needs redundant paths to the same LUN. You can create igroups that specify which initiators have access to the LUNs either before or after you create LUNs, but you must create igroups before you can map a LUN to an igroup.

Initiator groups can have multiple initiators, and multiple igroups can have the same initiator. However, you cannot map a LUN to multiple igroups that have the same initiator.

Note: An initiator cannot be a member of igroups of differing ostypes. Also, a given igroup can be used for FCP or iSCSI, but not both.

When you map the LUN to the igroup, you grant the initiators in the igroup access to the LUN. If you do not map a LUN, the LUN is not accessible to any hosts. Data ONTAP maintains a separate LUN map for each igroup to support a large number of hosts and to enforce access control.

You map a LUN to an igroup by specifying the following attributes:

LUN name: Specify the path name of the LUN to be mapped.
Initiator group: Specify the name of the igroup that contains the hosts that will access the LUN.
LUN ID: Assign a number for the LUN ID, or accept the default LUN ID.

Typically, the default LUN ID begins with 0 and increments by 1 for each additional LUN as it is created. The host associates the LUN ID with the location and path name of the LUN. The range of valid LUN ID numbers depend on the host. For detailed information, see the documentation provided with your host attach kit.

Guidelines For Mapping LUNs To igroups:

Use the following guidelines when mapping LUNs to igroups:

The following table provides details on igroup operations.

Like igroups, portsets are also used to control access to LUNs. They are used in association with igroups to restrict access based on the iSCSI/FCP ports.

If an igroup is not associated with a portset then an initiator that belongs to that igroup can see its target LUNs on all ports. If a portset is bound to an igroup then the initiator that belongs to that igroup can only see its target LUNs on the ports that belong to the portset.

The following table provides details about portset operations:

You can retrieve information on iSCSI Initiators connected to the NetApp storage system. An iSCSI session can have zero or more connections. Typically a session has at least one connection. Connections can be added and removed during the life of the iSCSI session.

The following provide the details:

The following table provides details on how to retrieve iSCSI statistics from NetApp Storage:

iSCSI PDUs received: This section lists the iSCSI Protocol Data Units (PDUs) sent by the initiator. It includes the following statistics:

iSCSI PDUs transmitted: This section lists the iSCSI PDUs sent by the storage system and includes the following statistics:

iSCSI CDBs: Provides statistics associated with the handling of iSCSI Command Descriptor Blocks, including the number of blocks of data transferred, and the number of SCSI-level errors and successful completions.

iSCSI Errors: Provides details of failures and other SCSI protocol errors.