Internet Storage Name Service
The Linux SCSI Target Wiki
|This article needs a review and may need a cleanup or additional content. Please help improve this article to meet our quality standards. (11/28/2010)|
The proposed Internet Storage Name Service (iSNS) protocol allows automated discovery, management and configuration of LinuxIO devices on a TCP/IP network across multiple discovery domains and discovery domain sets (optionally using iFCP gateways).
iSNS provides management services similar to those found in Fibre Channel networks, allowing a standard IP network to operate in much the same way that a Fibre Channel SAN does. Because iSNS is able to emulate Fibre Channel fabric services and manage both iSCSI and Fibre Channel devices, an iSNS server can be used as a consolidated configuration point for an entire storage network. However, standards-compliant iSNS implementations are required to support the iFCP protocol, supporting the iSCSI protocol is optional.
The iSNS standard defines four components:
- The iSNS Protocol
- iSNSP is a protocol that specifies how iSNS clients and servers communicate. It is intended to be used by various platforms, including switches and targets as well as server hosts.
- iSNS Clients
- iSNS clients are part of iSNSP aware storage devices. iSNS clients initiate transactions with iSNS servers using the iSNSP, register device attribute information in a common Discovery Domain (DD), download information about other registered clients and receive asynchronous notification of events that occur in their DD(s).
- iSNS Servers
- iSNS servers respond to iSNS protocol queries and requests made by iSNS clients using the iSNSP. iSNS servers initiate iSNSP State Change Notifications and store properly authenticated information submitted by a registration request in an iSNS database.
- iSNS Databases
- iSNS databases are the information repositories for iSNS server(s). They maintain information about iSNS client attributes; while implementations will vary, a directory-enabled implementation of iSNS, for example, might store client attributes in an LDAP directory.
- iSNS Control Node Client
- an iSNS control node client can facilitate administrative operations. Multiple implementations exist.
Control Node Client
There is no need to setup an iSNS Control Node Client in order to run the iSNS server with non-control node clients. Without an iSNS Control Mode Client, this will start the daemon and accept clients into the the Default Discovery Domain:
There is long-term interest to provide iSNS using software RFC 4171 heartbeat (implemented by the original author, and still present today). Also, a long-term option is using LIO T/I mounts using Linux/HA H+A with iSNS server as a cluster resource.
iSNS client scripts
The iSNS Control Client from LIO is directly based on the Linux/iSNS Project. Additional iSNS control client functionality and scripts have been included. The iSNS control client is stable, and is currently being used on Linux-IO.
- Obtain a list of both Initiator nodes+alias:
- Obtain a verbose list of iSCSI nodes+alias+portals+EIDs:
- Obtain a verbose list of LIO nodes+alias+portals:
- Determine if the local Initiator node has a valid EID:
- Determine if the local LIO node has a valid EID:
- Obtain a verbose list of Initiator and LIO nodes+alias+portals:
- Register both Initiator and LIO nodes from an ISNS Server:
- Deregister both Initiator and LIO nodes from an iSNS Server:
- Update Network Portal Information based on LIO stack settings (target only):
- Deregister and register both Initiator and LIO nodes from an iSNS Server:
iSNS Control Node Client scripts
- Check whether the associated iSCSI node is a control node:
- Check whether the associated iSCSI node is registered with the Server: <ocde>/isns/isns_is_node_registered <ip_addr></code>
- List all iSCSI nodes in the database:
- List details of the iSCSI node:
/isns/isns_list_node_detail <ip_addr> <node_name>
- List all iSCSI nodes of a discovery domain:
/isns/isns_list_dd_members <ip_addr> <dd_id>
- List all discovery domains:
- Create a discovery domain:
/isns/isns_create_dd <ip_addr> <DD_symbolic_name>
- Delete a discovery domain:
/isns/isns_delete_dd <ip_addr> <dd_id>
- Add an iSCSI node to a discovery domain:
/isns/isns_add_node_to_dd <ip_addr> <dd_id> <node_name>
- Remove an iSCSI node from a discovery domain:
/isns/isns_remove_node_from_dd <ip_addr> <dd_id> <node_name>
- List details of the discovery domain set:
/isns/isns_list_dds_members <ip_addr> <dds_id>
- List all discovery domain sets:
- Create a discovery domain set:
/isns/isns_create_dds <ip_addr> <DDS_symbolic_name>
- Delete a discovery domain set:
/isns/isns_delete_dds <ip_addr> <dds_id>
- Enable a discovery domain set:
/isns/isns_enable_dds <ip_addr> <dds_id>
- Disable a discovery domain set:
/isns/isns_disable_dds <ip_addr> <dds_id>
- Add a discovery domain to a discovery domain set:
/isns/isns_add_dd_to_dds <ip_addr> <dds_id> <dd_id>
- Remove discovery domain from a discovery domain set:
/isns/isns_remove_dd_from_dds <ip_addr> <dds_id> <dd_id>
- The scripts are meant to be used by the iSNS GUI for managing control nodes.
- String arguments which contain spaces must be enclosed in double quotes.
The sourcecode is available from the iSNS repository (see also README). It should build on any 2.4 or 2.6 Linux machine. Also, there is code to support other build platforms aside from the original Linux/iSNS sourcecode.
This original single threaded iSNS server design has been stable for some time, and suffices for moderate loads on modern iSNS clients. linux-iscsi.org allows to buld these RPMs for a simple iSNS server today. The original iSNS server by IPS TWG was licensed under a BSD license, and the new linux-iscsi.org version is also available under a BSD license.
The new iSNS server code still requires work to fully achieve production quality. E.g., the completion of asynchronous event handling on both client and server is an ongoing effort by numerous parties. A number of Linux vendors have been working on implementing iSNS functionality in their products, too. Examples for configurations of these implementations can be posted here as a community resource.
The following example is based on the Sony PlayStation 3 with Fedora Core 5.
[root@ps3-cell isnsserver]# ARCH=powerpc ./autoconfig --write-to-file
.make_autoconfig file should look as follows (some of the resulting output has been removed for simplicity):
[root@ps3-cell isnsserver]# cat /usr/src/linux-iscsi.org/trunk/isnsserver/.make_autoconfig ARCH?=powerpc AUTO_CFLAGS?= -I/lib/modules/2.6.23-rc5/source/drivers/scsi DUSE_COMPAT_IOCTL -DPYX_ISCSI_VENDOR='"Linux-iSCSI.org"' -DIQN_PREFIX='"iqn.2003-01.org.linux-iscsi"' -DLINUX -DLINUX_SCATTERLIST_HAS_PAGE -DSVN_VSN=\"58\" BASENAME?=FedoraCore-R5-Bordeaux.powerpc DISTRO?=FEDORA ISNS_VERSION?=18.104.22.168 OSTYPE?=LINUX RELEASE?=2.6.23-rc5 RELEASES?=ARRAY(0x102047a4) RPM_DIR?=/usr/src/redhat SNMP?=0 SYSTEM?=FedoraCore-R5-Bordeaux VERSION_IPYXD?=
Upon request, we can also provide linux-iscsi.org users and developers with a public iSNS server service.
- Q: What are the key optional defined features for iSNS clients that are a requirements for iSCSI Active-Active Connection Recovery?
A: State Change Notification and Entity Status Interval.
- Q: What is the status of these features in other iSNS clients?
A: They have been gradually appearing in a larger number of environments as IP storage systems gain momentum.
- Q: When will iSNS be available from linux-iscsi.org?
A: Currently, there are a few iSNS servers that implement various levels of the RFC. There is iSNS server code available from the iSNS repository. An open source iSNS client and server containing State Change Notification and Entity Status Interval is expected to proliferate as more LIO systems are coming online.
- Q: How can I change which node the iSNS server allows registering as a control node client?
A: This is a feature that is on our roadmap.
- RFC 4171: Internet Storage Name Service (iSNS)
- RFC 1034: Domain names - concentps and facilities
- RFC 1035: Domain names - implementation and specification