|
|
|
|
|
Internet Storage Name
Service is a discovery and name services proposal under
consideration by the Internet Engineering Task Force.
|
|
BY TOM CLARK
|
|
As the repositories of
information that sustain institutions and enterprises, storage
devices are at the center of modern network designs.
High-speed access and high availability of stored data are now
critical for both internal business operations and external
e-commerce applications. Storage devices, however, are unique
components in network design with their own specific
requirements. Unlike hosts in a typical data-communications
network, storage devices do not initiate transactions. In the
vocabulary of storage administration, storage devices are
targets, responding to read-and-write requests from initiators
such as servers or workstations. In direct SCSI-attached
storage configurations, a server can easily discover the
storage resources at its disposal by polling the SCSI bus to
which disk arrays are attached. Since the server is the
exclusive owner of its attached storage, it can be assumed
that any devices it discovers are available for its use.
|
|
In a storage area network
(SAN), by contrast, disk and tape resources may be dispersed
across a complex network. This presents challenges for device
discovery as well as device ownership. Initiators must be able
to identify storage resources in the SAN and determine whether
they have access to them. SANs therefore require a mechanism
to facilitate device discovery and to assign potentially
shared storage resources to specific initiators. In this
article, we will examine device discovery in storage networks
and how the Internet Storage Name Service (iSNS) can be used
to facilitate discovery in IP SANs.
|
|
|
Fibre Channel SANs support two
basic topologies: arbitrated loop and fabric. An arbitrated
loop is a shared medium, analogous to a Token Ring LAN.
Devices attached to the loop must arbitrate for access to the
shared bandwidth before launching transactions, and only 126
end nodes are supported. Fabrics provide full bandwidth to
each device and can support up to 15.5 million end nodes. The
topologies can be combined: A loop segment can be attached to
a fabric switch to allow communication between loop nodes and
fabric-attached nodes.
|
Figure 1: The iSCSI, iFCP, and FCIP protocols support a
serial SCSI-3 interface to the standard SCSI command set
expected by the operating system and upper-layer applications.
Discovery in an arbitrated loop
relies heavily on the limited number of devices that can be
connected to a single loop. Following loop initialization, an
initiator such as a server simply can poll through the 126
possible addresses to solicit responses from potential
targets. Walking the address space for 126 possible
destinations may be inefficient but occurs fairly quickly at
gigabit speeds. Targets that respond to an initiator's queries
verify their presence on the loop, and an initiator can
thereafter establish sessions with each device and begin
storage transactions. In some proprietary implementations, a
positional map generated during loop initialization is used
for target discovery. Each active device records its loop
address in the positional map, and the map, in turn, can be
used to create an address list for session establishment.
While this shortens the process of device polling, not all
loop devices support the positional mapping feature.
|
|
With more than 15.5 million
possible addresses, device polling is not a viable solution
for Fibre Channel fabrics. Fibre Channel standards therefore
provide a name service definition that enables device
discovery without walking an enormous address space. Whereas
in loop environments the initiator must perform all the work
of device discovery, in fabrics this responsibility is shared
between initiators and the Fibre Channel switches that compose
the fabric topology. A device attached to a fabric switch must
first log on to the fabric to obtain a unique network address.
It then registers its presence on the fabric by logging on to
the Simple Name Server (SNS) at a well-known address. The SNS
maintained by the switch is a small database that contains the
permanent device identifier, fabric address, class of service
parameters, and other information. Of special importance for
device discovery, the SNS provides an entry for the type of
upper-layer protocol supported, which for storage applications
is serial SCSI-3. Since every target device registers with the
SNS, an initiator simply can send a query to the SNS asking
for a list of all devices that support serial SCSI-3 protocol.
The address list that is returned from the SNS becomes the
polling list for the initiator, which then can send port
logins to the listed targets and establish sessions with them.
|
Figure 2: Because FCIP tunneling requires both IP and Fibre
Channel management applications, additional overhead is
necessary for a tunneled solution.
In some cases, it may not be
desirable for an initiator to discover all possible targets in
the fabric. An NT server, for example, probably should not be
allowed to discover and establish a session with a Unix
storage array since NT would overwrite the array's boot sector
and render it useless to Unix. Given that the SNS reports only
addressing and protocol support information, there is no means
within the SNS itself to restrict discovery of targets. In
Fibre Channel fabric switches, segregation of devices is
possible only through a technique called zoning. Zoning
creates groups of devices authorized to communicate, either on
the basis of port attachment or via World Wide Names. In some
implementations, zoning definitions override an initiator's
SNS query, and so the SNS reports only those target addresses
that are in the same zone as the initiator. This leaves the
initiator safely ignorant of other storage resources.
|
|
A third, related component of
device discovery accommodates changes that may occur once
devices have been discovered. The state change notification
service is provided by a facility within the fabric that
allows initiators to be notified if storage resources are
removed or added to the network. State change notification (SCN)
enables active responses to resource availability. For
example, if a new storage resource enters the fabric,
initiators can be notified and quickly establish sessions with
it.
|
|
One of the main issues of Fibre
Channel device discovery is scalability. Each fabric switch
maintains its own SNS database. As more switches are added to
a single fabric, they must be able to share SNS data so that
an initiator anywhere on the network can discover viable
targets. In addition, since zoning may be used to restrict the
discovery process, zone information also must be exchanged.
This scheme places an ever-increasing burden on switch
resources as SANs scale from small departmental configurations
to much larger implementations. Network convergence time is
adversely impacted by the greater latency of a large network
as switches update each other with SNS, zoning, and SCN
information.
|
|
|
While Fibre Channel has been
forced to pioneer device discovery techniques where no
precedents existed, IP-based SANs are able to draw from both
IP networking applications such as Domain Name Server (DNS) as
well as Fibre Channel SNS, zoning, and SCN. Nishan Systems
authored the first comprehensive discovery proposal for IP
storage, which has been submitted for standardization to the
Internet Engineering Task Force (IETF) as an iSNS draft. iSNS
leverages the database objects of SNS as well as familiar DNS
techniques to create a discovery mechanism that can be
distributed or centralized.
|
|
|
Because IP storage solutions
can be based on several distinct protocols, iSNS provides
support for a variety of implementations of block storage over
IP. The three main protocols for IP SANs are Fibre Channel
over IP (FCIP), Internet Fibre Channel Protocol (iFCP), and
Internet SCSI (iSCSI). As shown in Figure 1, the iSCSI, iFCP,
and FCIP protocols support a serial SCSI-3 interface to the
standard SCSI command set expected by the operating system and
upper-layer applications. This allows conventional storage I/O
to be performed over a high-performance gigabit transport.
Serial SCSI-3 transactions are carried over TCP/IP, although
only iFCP and iSCSI leverage native TCP/IP for each storage
end device. Each IP storage protocol has unique requirements
for discovery.
|
|
FCIP is used to tunnel Fibre
Channel traffic between two geographically separate Fibre
Channel SANs. As shown in Figure 2, frames originating on one
SAN are wrapped in IP packets and forwarded to the destination
SAN. At the receiving end, the IP header is removed and native
Fibre Channel frames are delivered to the fabric. A Fibre
Channel fabric switch then makes the decision as to which end
device the frame is intended for. In terms of discovery, the
only devices that have IP addresses are the FCIP gateways
themselves. IP discovery is thus limited to the FCIP gateways,
while Fibre Channel discovery and management is still required
for the storage end devices. Since FCIP tunneling requires
both IP and Fibre Channel management applications, additional
overhead is necessary for a tunneled solution. Due to the
limited management requirements of FCIP gateways, FCIP is not
included in the discovery and management services provided by
iSNS.
|
Figure 3 (left): Storage devices can be dispersed
throughout an IP network without being confined in Fibre
Channel SANs. Figure 4 (right): iSCSI end devices can be
connected by conventional IP routers and switches, which has
the advantage of native IP attachment but does not accommodate
existing Fibre Channel devices.
While FCIP can only connect
Fibre Channel SANs, iFCP is used to connect individual Fibre
Channel devices over an IP-based SAN. As shown in Figure 3,
storage devices can be dispersed throughout an IP network
without being confined in Fibre Channel SANs. iFCP storage
switches are a direct replacement for Fibre Channel switches,
which implies that iFCP needs something comparable to SNS for
end node discovery. This function is included in iSNS. In
addition to a 3-byte Fibre Channel address, an iFCP switch
assigns a 4-byte IP address to each Fibre Channel end node.
When a Fibre Channel device sends an SNS query, the request is
intercepted by iSNS. At the Fibre Channel layer, a list of
appropriate target addresses are reported to the initiator,
while the IP "storage-aware" fabric handles the
mapping of Fibre Channel addresses to their corresponding IP
addresses to link devices across the IP network. The list of
iSNS entries for iFCP devices therefore includes standard
Fibre Channel-specific objects such as port address and upper
layer protocol support (e.g., SCSI-3) and IP-specific entries.
|
|
iSCSI is a start-from-scratch
reconstruction of a serial SCSI-3 over the IP stack and
assumes that both initiators and targets are native iSCSI
devices. As shown in Figure 4, iSCSI end devices can be
connected by conventional IP routers and switches. This has
the advantage of native IP attachment, but does not
accommodate existing Fibre Channel devices. For iSCSI
implementations, a gateway is required to bring both iSCSI and
Fibre Channel devices into the same network. For an iSCSI
initiator to discover iSCSI targets, it needs to identify
which devices in the network are storage resources and what IP
addresses it needs to access them. A query to an iSNS server
consequently returns a list of IP addresses that the initiator
has permission to access.
|
|
An enterprise network may
contain all three IP storage protocol implementations, which
presents an additional challenge for any discovery method.
While FCIP will maintain Fibre Channel mechanisms for
discovery, iSNS accommodates diversity across devices by
including mechanisms for iSCSI and iFCP as well as future
native IP storage protocols that may emerge.
|
|
For more information on iSNS,
visit
www.ietf.org/internet-drafts/draft-ietf-ips-isns-03.txt
|
|
|
|
Tom Clark is director of
technical marketing at Nishan Systems. He is also a board
member of the Storage Networking Industry Association (SNIA),
co-chair of the SNIA Interoperability Committee, and the
author of Designing Storage Area Networks: A Practical
Reference for Implementing Fibre Channel SANs (Addison
Wesley Longman) and IP SANs: A Guide to iSCSI, iFCP, and
FCIP Protocols for Storage Area Networks, ISBN:
0-201-75277-8 (Addison Wesley Longman, November 2001).
|
|
|
|
|
DECEMBER
SPECIAL REPORT:
|
|
IP Storage: An in-depth
analysis of the IP Storage standards under development,
including iSCSI, iFCP, FCIP, iSNS, and more. In this
collection of articles, we'll also position IP Storage against
existing and future SAN technologies such as Fibre Channel and
InfiniBand.
|
|
|
- DWDM for storage networking
and disaster recovery
- Bandwidth vs. latency in SAN
extensions
- Security for SAN/MAN/WAN
applications
- Inside the iSNS
specification
- Storage virtualization: Part
III
|
|
PLUS: Comdex New Products
Wrap-up
|
InfoStor November, 2001
|
|
|
|
|
|
