Granada Television installed Studio Network Solutions’ SANmp multi-platform, volume-sharing software in 10 of its editing suites at its Bristol, UK, location.
There has been much discussion (and a good dose of confusion) about the term “iSCSI” over the last year. This relatively new protocol for storage technology offers many compelling benefits, including solid performance and the ability to inexpensively create a storage area network (SAN) using standard Ethernet components.
But what exactly is iSCSI? Perhaps it is helpful to first touch briefly on what iSCSI is not. It is not networked attached storage (NAS). It does not require Small Computer Systems Interface (SCSI) disks. It is not a file-sharing protocol like those used by Mac and Windows servers. It is not Internet Fibre Channel Protocol (iFCP), a protocol used to connect Fibre Channel (FC) SAN islands across long distances. Nor is it Fibre Channel Over Internet Protocol (FCIP), a tunneling protocol used to extend or connect FC networks.
iSCSI is extremely close to the FC Protocol, which is designed for large data transfers with low overhead and low latency. For those already familiar with FC, iSCSI can be loosely generalized as “Fibre Channel over Ethernet.”
By definition, iSCSI (Internet SCSI or “SCSI over IP”) is a storage networking standard that enables the transport of block I/O data over an IP network. iSCSI replaces SCSI's direct-attached cabling architecture with a network fabric. Essentially, the protocol works by encapsulating SCSI commands into packets and transporting them via TCP/IP. In other words, an Ethernet network now has the potential to become a SAN. And as a direct result of this ubiquitous, standardized Ethernet infrastructure come many interesting features and benefits that would otherwise be impossible.
Figure 1. A typical iSCSI SAN.
Some might argue that simplicity is a key advantage of using iSCSI over FC to deploy a SAN. The reason: An iSCSI SAN doesn't necessarily require the specialized hardware knowledge that is perceived to be a prerequisite with FC. There is already an inherent level of familiarity with the various Ethernet networking components. Therefore, a company lacking a dedicated staff of storage network technicians should feel more adept at maintaining and troubleshooting an iSCSI SAN.
Where does it fit?
Although iSCSI can certainly be complementary to many other storage technologies, it is especially well-suited for a large portion of the middle market — that is, the mass of users who:
- Need considerably more throughput than NAS or client/server can provide.
- Desire the benefits of a SAN.
- Have determined FC is somewhat excessive for their needs.
An iSCSI SAN can be the solution here in that it provides comparatively excellent throughput, delivers the benefits of consolidated storage and requires fewer resources overall than FC in terms of people and cost.
The price and performance of iSCSI implementations for audio and video applications can vary widely. In a comparison of similar FC components, one can expect to save between 40 percent to 60 percent with iSCSI. It may be possible to use existing network interface cards (NICs), switches, etc., which would result in additional savings.
Performance is of highest importance when the storage network is expected to stream large amounts of audio or video — i.e., production or post using applications such as Digidesign's Pro Tools or Apple's Final Cut Pro. iSCSI can excel here, whereas the extreme throughput demands would usually relegate NAS and client/server to push/pull.
Figure 2. Typical iSCSI architecture
Benefits of iSCSI
The throughput levels achieved over a well-tuned Gigabit Ethernet (GbE) iSCSI SAN are surprising. This is especially apparent when compared to the performance of common file-sharing protocols over a similar network. The client/server and NAS protocols used for basic file sharing rarely match the efficiency of a block-level protocol such as iSCSI or FC. It is important to understand that those file-level protocols are better for users or applications that need to access a particular file, whereas block-level protocols are optimal for users or applications that constantly need the fastest access to data.
In general, the protocol is a key reason pure “wire speed” is almost never achieved. The constraint is not the available bandwidth (1Gb/s in this case). It is the overhead of the protocol being used. By employing a more efficient protocol, one can more fully use the bandwidth of the pipe. Conversely, if the pipe is the bottleneck, then a more efficient protocol won't help much.
Another significant benefit over FC is that an iSCSI SAN is capable of natively spanning great distances. It is common for networked storage to be located a fair distance from its consumers. It could be located down the hall or locked away in some data center. iSCSI is certainly comfortable within the local network.
But the task of securely extending storage — particularly SAN storage — can become complicated outside the immediate confines of a campus. iSCSI makes this much easier. Not only can a virtual private network (VPN) be used to securely extend an iSCSI SAN over a WAN, but also iSCSI supports the Challenge/Handshake Authentication Protocol (CHAP). CHAP is an advanced authentication mechanism that can help ensure that a user or server has the valid credentials to connect to a particular resource on a SAN.
An iSCSI initiator setting up the first connection to an iSCSI target.
VPN and CHAP can be used together or independently, depending on the desired level of security. A few applications for an iSCSI Storage WAN (SWAN) are:
- Remote mirroring.
- Offsite archive/backup.
- Disaster recovery.
- Content delivery.
iSCSI's compatibility with existing software applications is practically guaranteed. This is because iSCSI storage is presented to the OS as though it is attached locally, rather than presenting it as a network share. And because iSCSI storage is seen at the block-level, it is possible to use an operating system's native file system on those devices. Some applications simply will not run on storage that is presented as a network share. This is not a problem in an iSCSI environment.
Hardware requirements
At the basic hardware level, there are no special networking components required. (See Figure 1.) However, it is doubtful that much will be gained by using anything less than high-quality GbE components.
Figure 3. An example of tiered storage networking
Beginning from within the computer itself and working towards the physical storage, the first component to consider is the network interface. The integrated GbE NIC found in most computers is usually sufficient for SAN connectivity. If performance becomes a problem, consider upgrading the NIC. The alternative is to use a TCP/IP offload engine (TOE) on the NIC or host bus adaptor (HBA). This deals with the additional TCP flow, thus reducing the possibility of the host's CPU becoming an I/O bottleneck. There is heated debate as to the optimum solution. One side favors the concept of the TOE; the other believes the cost of a TOE should simply be applied towards a faster CPU.
Special cabling is not required other than that which is necessary for GbE. High-quality Category 5e cable is recommended. Although it is usually more expensive, plenum-rated cable should be used when safety regulations or compliance codes dictate.
A managed Layer 3 Ethernet switch is sufficient for the majority of iSCSI SANs. The configuration of the switch itself is of paramount importance. There can be thousands of settings in a high-quality GbE switch. As with most things, reading the manual and learning the “ins and outs” of the device can be the difference between unparalleled success and miserable failure.
iSCSI details
iSCSI works by encapsulating SCSI commands and transporting them via TCP/IP. On opposing ends of the network are the pillars of iSCSI: the initiator and the target. The initiator, which can be in the form of hardware or software, is installed on the host. The most basic responsibilities of the initiator are to establish a connection to an iSCSI target and start the transfer of information to and from it. (See Figure 2 on page 76.)
Configuring the initiator so that it is capable of connecting to a given target is quite simple. (An example is shown in the screen shot on page 76.) Connection information can be made persistent so that the setup need only be done once per target.
The iSCSI target's primary function is to respond to the requests started by the initiator. This task is accomplished by brokering the requests of the initiator to the physical storage. The iSCSI target most often takes the physical form of a storage appliance, although there are software-only products available as well. Regardless of the format, the iSCSI target acts as the bridge between the network and the disks — usually a RAID of Serial ATA drives.
A common question is whether a separate network should be implemented for the iSCSI traffic. The correct answer to this question requires close examination of the intended purpose and expected throughput of the iSCSI SAN.
In small installations constrained by budget, there often is no choice but to use the existing infrastructure. If this is the case, it must be accepted that any IP-based solution could possibly suffer due to the existing traffic on the network. Therefore, an iSCSI SAN will still perform better than the available alternatives simply because of the efficiency of the iSCSI protocol.
To guarantee the highest performance and stability, it is recommended to implement a dedicated IP infrastructure for the iSCSI SAN. A compromise between these two approaches is to implement a virtual LAN (VLAN) to isolate the iSCSI traffic on an existing infrastructure.
Implementation
It is probable that a broadcaster already has an assortment of storage and networking technologies in place. Some may be for back-office functions and some for media networks. When deployed correctly, iSCSI can be complementary to existing storage/networking systems.
iSCSI need not be viewed as an either/or solution. Nowhere is this truer than with FC. Consider, for example, a FC/iSCSI hybrid SAN. This opens the door to tiered storage networking. (See Figure 3.) Here, it is possible to extend FC only to those that need the highest performance, while routing the FC SAN over iSCSI to the remainder of users or servers. There are several bridging and routing devices available that are capable of extending iSCSI connectivity to various protocols.
The demand for iSCSI is predicted to accelerate steadily over the next several years. It is hard to ignore the benefits of SAN, let alone one that is implemented on common network components. The fact is that iSCSI is firmly situated on top of the two most ubiquitous network standards: TCP/IP and Ethernet. Its value proposition becomes even more apparent with the realization that Ethernet economics now can be applied to an organization's SAN strategy.
Some have even predicted that iSCSI signals the demise of FC. The more likely outcome (near-term at least) is that iSCSI will find its way alongside many FC implementations. But perhaps nothing stands to solidify the position of iSCSI more than the mass adoption of 10GbE. With five times the bandwidth of most FC products sold today, 10GbE currently sits quietly in the background — an inevitable giant in waiting.
Eric Newbauer is director of operations for Studio Network Solutions.
