Enterprise Networking Planet content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
We all agree that iSCSI is extremely flexible and useful, but a big pain point in enterprises these days is the management of iSCSI devices. You manually configure each storage device, and then manually configure all your iSCSI initiators to connect. There has to be a better way. Thankfully, the Internet Storage Name Service (iSNS) protocol is here to save you.
Many sites have more than one vendors’ iSCSI implementation in use. IP storage has become very popular, but as you begin to take advantage of this great technology, it becomes apparent that it’s not as manageable as traditional FC-based SANs.
In this article we will explain the iSNS protocol and let you know what your iSNS server options currently are. Next week, we will demonstrate how to set up and configure the Sun iSNS server.
First, let us clarify some basic iSCSI concepts to ensure we’re all on the same page. An iSCSI “client” is an initiator, which is a direct translation of the SCSI protocol. Therefore, the “server” providing the storage is known as the target. Each device shared is a unique target, and the initiator discovers them, then attempts to connect. Part of the iSCSI discovery protocol states that target devices must support the “send targets” command, which will allow an initiator to login to each available target.
iSNS
The iSNS protocol (RFC 4171) was developed to provide a central management point for all iSCSI devices. Discovery and management provided by iSCSI-enabled devices is often quite rudimentary and inadequate. For example, a discovery run in Linux results in the initiator logging in to every available target on the server, which is almost never what you want. Instead, we can discover targets via an iSNS server, which will control what is seen.
An iSNS server sits between iSCSI initiators and targets, brokering protocol-level communication much like a Web proxy server. The actual iSCSI traffic does not flow through the iSNS server, but the management functions such as discovery and the configuration of targets can be centrally managed. Both targets and initiators must be configured to use an iSNS server, which is supported by all compliant iSCSI devices.
The iSNS protocol can also act as a central management point for Fibre Channel (FC) SANs that use the iFCP protocol, allowing for centralized management of both traditional FC and IP SANs. A big advantage of an iSNS server is that it implements more advanced services normally found only on FC fabrics. Messages can be sent, notifying all iSNS speakers of information, and of course, it provides that central management function most iSCSI users are yearning for.
iSNS in Depth
The iSNS Protocol, or iSNSP, defines how iSNS clients and server communicate. This is where it may get a tad confusing. All your iSCSI “clients” (initiators) and “servers” (targets) are, in fact, iSNS clients. Regardless of a storage device’s function, it must act as a client when communicating with the iSNS server.
The iSNS protocol provides four basic functions to simplify and upgrade your iSCSI infrastructure management.
First, iSNS servers allow registration. Both targets and initiators register with a central database, and they can query it for information. Without iSNS, you must configure each initiator individually to know about every other storage device—an NxN problem that quickly becomes unmanageable.
Second, an iSNS server provides authentication and the ability to configure multiple Discovery Domains (DD). The DD controls which initiators will “see” which targets; think of it like soft zoning in FC fabrics. On the authentication front, all your storage providers and consumers can be configured to authenticate with one server, instead of manually being configured for a connection with each other.
Third, the State Change Notification service turns an IP network into a more state-full and aware network, akin to Fibre Channel. The most prevalent state change in FC fabrics is the joining and leaving of devices. An IP storage network is oblivious to such changes, but when an iSNS server is brokering registrations, it is in the perfect position to provide such information. Event notifications also notify iSNS clients about network events that may affect the operational status of the storage network. FC SANs are extremely robust and able to cope with failures, due in large part to event notifications. Now, IP storage networks can implement many of these same features, as well as interoperate with FC SANs.
Finally, iSNS’s role is also to map between iSCSI and FC devices. It does this by mapping iSCSI devices to proxy World Wide Names (WWNs), which can in turn be used by iSCSI-FC gateways. This is the “glue” that makes integration between the two storage networks possible.
iSNS Servers
The bad news here is that not many iSNS servers exist.
Microsoft’s iSNS Server 3.0 product available as a free download.
Linux also has an iSNS server, but it’s not available via most distributions. You must download the source and compile it yourself. The documentation is scarce, and there are still a lot of outstanding features yet to be implemented. It is, essentially, and abandoned project.
Sun, fortunately, has had a fully supported iSNS server available in OpenSolaris since build 77. The latest OpenSolaris release is build 101, and includes the iSNS server. This is the most feature-rich iSNS server available, and it even includes a GUI interface (installed separately).
Next week, we’ll explain how to set up the OpenSolaris iSNS server and register your clients to help you on your way to a manageable IP storage network.
