Storage area networks (SANs) and network-attached storage (NAS) are both designed to give IT managers shared, remotely attached data storage options but both approaches have their problems.
SANs implement dedicated connections between storage and processors, offering low-latency high-bandwidth data channels. SANs also let processors address individual blocks of storage, ensuring efficient random access. What SANs do not provide natively is file sharing-- each disk or partition can only be accessed by one server. There are now software solutions that allow file sharing across SANs, but these still require new skills to implement.
NAS does provide native file sharing and allows data access across traditional LAN infrastructures. But the use of file sharing protocols, such as Common Internet File System (Cifs) or Network File System (NFS), means that only file-level access is possible. This makes accessing small parts of larger files--such as in database access--inefficient.
Cheaper alternative
Most enterprise firms implementing SANs will need to invest in infrastructure and skills, through hiring new staff or retraining existing employees. While the Fibre Channel (FC) interface most commonly used to interconnect SANs is not an overly complex technology, there are different management tasks involved in running a SAN as opposed to a LAN.
To provide a cheaper alternative to FC-based SANs--one that retains many SAN benefits but avoids the need for new infrastructure and skills--the iSCSI protocol has been created. ISCSI is a new proposed standard designed to transport SCSI protocols across TCP/IP. This allows the use of remote-block I/O using existing LAN and WAN equipment, which means there is no need to retrain staff or install new equipment. Because iSCSI is based on TCP/IP, standard network interface cards (NICs), hubs, routers and cabling can be used to provide the physical transport. The iSCSI protocol has been submitted to the IETF for standardisation, and has the backing of IBM, Cisco, HP, EMC, Adaptec and Quantum.
Native SCSI, as used in directly attached storage, is a protocol and a physical transport. With iSCSI, the latter is substituted with the transport provided by TCP/IP. For this to work, the SCSI protocol, which normally works with a parallel transport, had to be expanded to let it function with a serial network transport.
ISCSI-based SANs attach the disks and tape drives themselves to a storage router or dedicated iSCSI storage device. The router or storage device has a number of SCSI ports and a network interface. The device itself manages which iSCSI clients (or initiators) have access to which iSCSI storage devices (or targets). Since SCSI protocols are being used, logical unit numbers (LUNs) within iSCSI targets can also be assigned, which makes it possible to have a redundant array of inexpensive disks (Raid) attached to an iSCSI storage management device.
The easiest way for IT managers to add iSCSI capabilities to a storage server is with a driver that uses the existing TCP/IP stack. The driver provides one or more virtual SCSI channels for the operating system and other applications to use. This requires no additional hardware in the server, but there is the processing overhead of protocol translation. It would be possible to build a bridge that attaches to a server's existing SCSI ports, but the cost would be prohibitive and it is unlikely we will see such a device.
An iSCSI driver presents itself to the operating system as a standard SCSI driver, so any file system or application trying to access iSCSI storage does not need to be altered in any way. When the driver receives a request from an application, the SCSI commands are packaged into iSCSI messages and sent over the network to the target. The response returned is similarly translated back to SCSI responses.
ISCSI is a session-based protocol, using one or more TCP connections for one session. The first phase of every session is a login phase. Authentication information may be exchanged between the initiator and the target, and if the login is successful, iSCSI parameters are negotiated. ISCSI also includes the facility for using either no authentication--or a combination of authentication and data encryption--depending on existing network security levels. Similarly, iSCSI data can be tunnelled over IPSec virtual private networks (VPNs) in the same way as other IP traffic.
After login is complete, other TCP connections can be added to the same session. ISCSI sessions and commands are numbered, so there is no risk of data being returned in response to the wrong command or instructions being followed out of the correct order.
Several mechanisms are available for an iSCSI initiator to find targets. Each target has an iSCSI address--similar to a URL. Using the domain name system (DNS) address that forms part of the iSCSI address, the IP address of the target can be located. The iSCSI address of suitable targets can come from a number of sources: targets can either be directly configured in the initiator, or the target name can be supplied by a default iSCSI device based on the initiator's address. Alternatively, targets can be located by using service location protocol (SLP) multi-casts, or by querying a storage name server for a list of targets.
Target location options
Pre-allocation is the simplest and least flexible addressing scheme. Configuring addresses in each initiator requires the most maintenance, since each initiator will have to be reconfigured when the IT manager wishes to change the iSCSI storage structure. Similarly, using a default target allows slightly more central control over which initiators use which targets, but may require reconfiguration of targets.
Dynamic allocation by SLP or a storage name server lets administrators hold the mappings of initiators to targets centrally, and to reconfigure what storage is available to which with little effort. Of the two, SLP has the least impact, since it is capable of working without a central server, but can do so with greater efficiency.
Because iSCSI is block-based, targets cannot be shared between initiators natively. This would require additional software to arbitrate between the different initiators wanting to access the same target. Fortunately, the technology required to do this is similar to that used to enable file sharing on FC-based SANs, and as such is unlikely to present a problem.
The idea of implementing a SAN using a firm's existing Ethernet infrastructure sounds all very well, but IT managers may find the reality somewhat different. Those using 100Mbit/s Ethernet, even a dedicated switched connection between initiator and target, will be lucky to achieve 10Mbit/s throughput--poor by comparison with current directly attached SCSI storage speeds. To achieve similar performance to directly attached storage or FC-based SANs, administrators will have to implement Gigabit Ethernet between all targets and initiators.
While this represents extra investment, it would be compatible with the rest of the company network infrastructure, and it may not be necessary to have separate storage and networking connections. IT managers should simply be aware that the total bandwidth available is shared between storage and other networking, and performance will be less than would be achieved with a dedicated SAN.
Running iSCSI over a WAN is simple, but performance suffers because data transfer rates are not likely to exceed a few dozen kilobits a second. However, a sensible backup system does not require large amounts of bandwidth and administrators should be able to carry out off-site backups directly across a WAN connection, although they should not expect remote disk mirroring in the absence of high speed links.
The simplicity with which iSCSI fits into existing protocols, equipment and ways of working should ensure that it becomes widely adopted. It may require the availability of 10Gbit/s Ethernet to replace FC where very high performance is required, but that should be ready in the near future. Until then, it still represents a far less disruptive way of implementing remotely attached storage.
