This article can also be found in the Premium Editorial Download "Storage magazine: Distance: the new mantra for disaster recovery."
Download it now to read this article plus other related content.
The iSCSI roadmap
Before iSCSI can gain momentum with users or vendors, a number of scenarios need to play out in the coming months and years.
First and foremost, there has to be a greater adoption rate of SANs across the industry, regardless of the protocol adopted. According to Randy Kerns from the CO-based Evaluator Group, the deployment rate of FC SANs in large organizations is now approximately 70%. Yet across midsize and small organizations, International Data Corporation (IDC), Framingham, MA, reported last year that the deployment rate for SANs for these organizations is still at or below 25%.
|Can I use what I already have?|
iSCSI may help to jump-start SAN adoption in smaller companies because as IDC reported, the primary obstacles were the cost of deployment and trained support staff. iSCSI helps to eliminate these initial barriers and should help to spawn the other storage management technologies needed to manage this new storage infrastructure.
Second, iSCSI must continue to answer the nagging performance questions. The additional overhead required on a server's CPU to process the storage traffic plus the additional network traffic generated by iSCSI may grind some deployments to a halt. However, new network cards with embedded TCP/IP offload engines (TOEs) and faster network speeds may resolve this issue before it ever becomes a major problem.
Adaptec, Intel, and LSI Logic already ship cards that support these offload engines and the network capacity issue may resolve itself with the forthcoming 10Gb Ethernet technology. Says storage consultant Toigo: "While iSCSI networks max out at around 73% bandwidth utilization, the all-important question is: Does it matter? And with 10Gb Ethernet, bandwidth utilization largely becomes a non-issue."
A third issue that will be debated for some time to come is security. Adaptec's Clowney points out that while TCP/IP protocol processing consumes significant host CPU cycles for all communications-intensive applications such as file, caching and Web serving, the CPU cycles required for IP Security (IPsec) processing is actually much higher. While this technology will probably not be needed in most initial deployments of iSCSI SANs because they most likely will be separate dedicated networks, as these iSCSI SAN islands get connected, the importance of HBAs handling the IPsec offload is critical.
A fourth issue that's also germane to security is that of LUN security, which entails the mapping of SAN-attached disk drives to servers. HDS' director of product marketing, Jim Beckman, believes this will be handled in the iSCSI space similar to how it's currently handled in the FC space. In an FC SAN, each server has one or more host bus adapters (HBAs), each with a unique identifier referred to as a world wide name (WWN). This WWN is used to map and secure SAN-attached disk drives to the servers they are assigned to.
In the iSCSI space, Beckman says that instead of using a WWN, administrators will now use the media access control (MAC) Address. This MAC address is the network card equivalent of the FC HBA's WWN, where the MAC is the hardware address that uniquely identifies each Ethernet card on a network. In iSCSI environments, administrators will assign the MAC address to the iSCSI SAN-attached disk drive to map those disk drives to the servers who access the data on those disks.
Unfortunately, a major problem exists with this approach. Any simple search across the Internet on "MAC address spoofing" will unveil step-by-step instructions on how to change the MAC address on a network card on a Windows operating system. A simple change in the address of the MAC card--deliberate or accidental--could have unpredictable effects in terms of which storage is seen by which server on an iSCSI SAN.
Microsoft has found a different way of handling this LUN security issue with its upcoming release of its version of iSCSI. Connections between a server (the initiator) and the storage array (the target) will be made on the basis of these initiator and target names. These names roughly translate into IP address plus port number. In their implementation of iSCSI, they won't even attempt a connection without this information. By combining this precautionary measure along with challenge handshake authentication protocol (CHAP) for authentication, Microsoft believes this will provide a reasonable level of security for most environments.
Finally, iSCSI needs to work on cleaning itself up in the coming year. With prereleases, limited support releases, vendor-only supported releases and now the ratified release, it's going to take some time for the industry to sort itself out. Storage consultant Toigo says some engineers currently working on iSCSI can't decide whether to call this current release version 0.0 or version 1.0. With this much internal debate in engineering circles still going on, he believes another iSCSI release is in the cards to be released at approximately the same time 10GbE comes out in 2004. This potential second release--plus the introduction of 10GbE--should help to clarify the iSCSI picture and help move this segment of the industry ahead.
As users look ahead into the emerging iSCSI landscape, the view--with or without rose-colored glasses-- should start to come more clearly into focus. Microsoft recently threw a big bone to iSCSI with its announcement that in June it will make available a native iSCSI driver for its Windows 2000 servers and clients, Windows XP clients and its forthcoming Windows 2003 family of products. This will be available via a Web download at no charge.
Organizations supporting a number of Tier 2 or Tier 3 servers probably need to start putting iSCSI into their roadmap in controlled environments with non-mission-critical applications. Meanwhile, owners of Tier 1 apps should take a wait-and-see approach and let others work the inevitable kinks out of the iSCSI technology.
This was first published in May 2003