iSCSI is a relatively new and hot item in the IT
storage networking
technology (at the moment of writing there's nothing more than a
internet draft 7). I'm one of the lucky few who is allowed to work with it (ok, some not quite computer-oriented people might disagree with that).
Even though iSCSI is still in diapers with respect to the gory details, the general ideas will be the same.
And why yet another technology?
Besides to keep ourselves busy, it is supposed to make life easier for the
systems engineers and administrators. It appeared that systems engineers/administrators didn'r really want to start of building cool
Storage Area Networks (SANs) and their managers didn't like the price tags of all that. So to meet these aspects something differentwas created: iSCSI.
iSCSI benefits: connectivity, extended distance, media and network attachments (SWANs),
interoperability, backup, management, and low costs. Simpler to manage because you can existing
knowledge for configuring the whole lot, as oppsed to digging into fibre channel fabrics and so on.
iSCSI considerations: network
congestion, performance (but iSCSI performs better than NAS when both are on Ethernet due to reduced protocol overhead, data security, early life of technology.
in short:
"Use the existing network infrastructure, plug the extra required storage into your network and enjoy!". Well, sort of...
What is needed?
- The PCs in your network that you want to allow to make use of the storage need either a so-called "initiator", like a special
network card, or a standard network card with a special driver. Aka: there is a
hardware/software trade-off.
-
iSCSI converter/server; a dedicated PC with a few extra components like the interface to the network and to the storage and running an OS like
linux.
- Storage enclosures, i.e. boxes with a bunch of hard drives up to (a couple of) terabytes and some intelligence added to it for fault tolerance (
RAID) and environmental monitoring etc., or
tape drives for the back-up.
The technology
In normal
file I/O from your PC you make a request for a file to retrieve from some remote location, with iSCSI
block I/O is used.
The initial steps are the same as for a local or
SAN attached I/O request. The application program makes an I/O request, either to the
file system, or via a raw partition in the case of many
database applications. The I/O is passed to the SCSI
device driver. The iSCSI client (the initiator) has a special SCSI mini-port driver layer of software associated with the SCSI device driver, and/or is implemented in a hardware initiator. This is used to interface to
TCP/IP, and to encapsulate the SCSI commands into the TCP/IP stack. TCP/IP accesses the network device driver firmware of the Network Interface Card (
NIC), and transmits the I/O in SCSI blocks over the network to the iSCSI storage
appliance.
On arrival at the NIC of the target iSCSI appliance ("server side"), the I/O is passed through the receiving network device driver to the TCP/IP stack in the target. The iSCSI device driver layer de-encapsulates the I/O from TCP, and passes it to the SCSI device driver. From there it is handed on to the storage system bus adapter (the
HBA), and then to the disk array or tape drive.
The return journey is the reverse of the outbound route. Like the network file I/O, you can see that today there is a software stack processing overhead associated with an iSCSI I/O request. This has performance implications, but in general they are less than for a file I/O. The differences between storage protocol (block I/O) and network protocol (file I/O) are all about the location of the File System and where the translation to SCSI blocks takes place.
iSCSI-connected
disk volumes are visible to
IP network attached processors, and as such are directly addressable by database and other performance oriented applications. It is a connection alternative to Fibre Channel SAN, while a
NAS (Network Attached Storage) is an appliance.
Breaking it down into the the basic distict components:
- iSCSI operations: iSCSI is a connection oriented command/response protocol. An iSCSI session begins with an iSCSI initiator connecting to an iSCSI target (typically, using TCP) and performing an iSCSI login. This login creates a persistent state between initiator and target, which may include initiator and target authentication, session security certificates, and session option parameters.
- iSCSI data flow: The same TCP session used for command/status is also used to transfer data and/or optional command parameters.
- Layers and sessions: Communication between the initiator and target occurs over one or more TCP connections. The TCP connections carry control messages, SCSI commands, parameters and data within iSCSI Protocol Data Units (iSCSI PDUs). The group of TCP connections that link an initiator with a target, form a session (with session ID).
- Ordering and SCSI numbering: iSCSI uses Command and Status numbering schemes and a Data sequencing scheme.
- Command numbering and acknowledging: iSCSI supports ordered command delivery within a session. All commands (initiator-to-target) are numbered. The iSCSI target layer MUST deliver the commands to the SCSI target layer in the specified order.
- Login phase: The login phase establishes an iSCSI session between initiator and target. It sets the iSCSI protocol parameters, security parameters, and authenticates the initiator and target to each other. Operational parameters MAY be negotiated within or outside (after) the login phase. Security MUST be completely negotiated within the Login Phase or provided by external means. The whole login phase is considered as a single task and has a single Initiator Task Tag (similar to the linked SCSI commands).
- Security considerations: yes there are, they're working on it and have proposals.
- Initiator-target authentication: In this mode, the target authenticates the initiator and the initiator optionally authenticates the target. Not sending clear/plain password.
- Data integrity and authentication: This mode provides origin authentication and data integrity for every message that is sent after a security context is established. It is possible to use different authentication mechanisms for headers and data.
- Encryption: This mode provides data privacy in addition to data integrity and authentication, and protects against eavesdropping, man-in-the-middle attacks, message insertion, deletion, and modification.
Future??
The above is just a very brief overview (if you print the
draft it's over 80 pages and there are closely linked proposals dealing with the naming scheme etc and wite papers from CISCO, IBM,
SNIA papers etc) and as can be seen, the impelmentation currently is mainly in software (not brilliant from
performance point of perspective). Future
developments will be focussed on hardware initiators, the TCP off-load engines, using 1 Gb ethernet networks, 2 Gbps fibre channel storage and beyond. If the market is ready for it of course...
for the latest and greatest: http://www.ietf.org/internet-drafts/ or go straight to http://www.ietf.org/internet-drafts/draft-ietf-ips-iscsi-07.txt