Managing and protecting all enterprise data


Getting real about iSCSi

The picture of iSCSI is a little fuzzy. What advantages or disadvantages do you face if you implement now?

Vendors are starting to give rose-colored iSCSI glasses to their customers. The recent ratification of the iSCSI standard by the Internet Engineering Task Force (IETF) and Microsoft's heartfelt endorsement of the technology is hailed by some as the opening of a vast, new storage frontier. But despite the beautiful portrait that vendors try to paint about iSCSI nirvana, users need to see another picture: What will they experience if they implement iSCSI now or sometime soon?

The view of the iSCSI landscape depends heavily on whose glasses you peer through. Of course, the rose-colored ones cast iSCSI in an appealing light. iSCSI offers organizations the ability to utilize existing networking staff and infrastructure while promising increased storage utilization and cheap disaster recovery solutions.

The iSCSI performance impact
Does iSCSI slow down server and database operations? The short answer is yes. The TCP/IP protocol--without even considering iSCSI--generates a certain amount of overhead on every server's CPU. Data packets sent back and forth between computers must be built on the host computer, transmitted over the network, received and then broken back down again by the receiving computer. All this activity requires a certain amount of CPU power. However, with the fast processing speed of most systems today, this back-and-forth activity rarely is a problem. Still, the addition of the iSCSI protocol can add a significant amount of overhead to the CPU needed to process the TCP/IP stack.

In addition, Ethernet IP networks that support 1Gb speeds reach their capacity at approximately 70% bandwidth utilization and in some cases as low as 40%. This has to do with the fact that TCP/IP may lose packets during the transmission process. Error checking natively occurs in TCP/IP to ensure the successful transmission of packets occurred. If data packets do get dropped, the sending computer must resend the original packet. This situation only worsens if the network gets congested with too much data traffic.

To mitigate both of these performance issues, two new technologies are emerging. The first is already here. Ethernet Cards that contain TCP/IP offload engines (TOEs) offload the processing of the TCP/IP stack onto the card itself. They use application-specific integrated circuits (ASICs) that are specially designed to recognize the TCP/IP stack and process this protocol before the server's CPU has to deal with it.

The other technology looming large for 2004 comes in the form of 10Gb Ethernet. This helps answer many of the network congestion issues that may arise now. Even assuming a worst case scenario of 40% network congestion in a 10Gb environment, that still translates into network throughput speeds that are six times faster than the best performing 1Gb network today--more than enough to answer almost any of today's or tomorrow's performance issues. Until 10Gb Ethernet arrives, it's probably not wise to consider running an Oracle database with high I/O rates on a 1Gb network.

Yet iSCSI naysayers point to a lack of storage devices--such as tape and storage arrays--that currently support iSCSI. Toss into the mix the poorly deployed storage strategies many organizations have, plus those nagging TCP/IP performance questions and iSCSI can become a dangerous minefield of unforeseen problems.

While sending users into unexplored territory has never stopped vendors from selling products before, anyone seriously evaluating iSCSI must ask--and try to answer--the question of whether iSCSI is a dead-end road? And if your answer is: "No, it's not," the next question to ask is whether now is the right time to head down this path and if not now, when? The iSCSI roadmap answers some of these questions, but doesn't do a good job explaining what storage problems iSCSI creates as organizations try to figure out how to fit this new technology into their current infrastructure.

The iSCSI minefield
iSCSI's value proposition is strong. For example, today many Intel servers natively ship with dual network cards supporting up to 1Gb speeds and plug into Ethernet switch ports with costs running at or below $100 per port. This translates into a cost of as low as $100 per port or $200 per server, assuming a server deployment with redundant paths. Even assuming a worst-case scenario requiring the purchase of two network cards with TCP/IP offload engines for approximately $500 per piece, the cost to deploy an iSCSI Ethernet network still will run only one-seventh of the cost of deploying a comparable Fibre Channel (FC) network--a substantial difference by any measure.

According to Peter Hayden, the CEO of Nashua, NH-based EqualLogic, Inc., the cost to deploy an FC network costs approximately $3,500 per port or about $7,000 to deploy a server with redundant FC connections. While this cost may seem inconsequential for high-end Tier 1 applications, these connection costs exceed the costs of many off-the-shelf Intel servers today.

Of course, iSCSI deployment decisions shouldn't be based on just low hardware costs. Those who proceed without a clear understanding of the management issues associated with storage networking are looking for trouble. Buyer beware: Storage management issues and their associated costs loom large when deploying an iSCSI storage network. EqualLogic's Hayden says, "Hanging the wire helps, but does not solve the fundamental problem of storage networking, which is storage management."

Scott Robinson, the CTO for the Chanhassen, MN-based Datalink says, "iSCSI storage networks will have fairly dramatic different service level expectations for storage traffic than traditional Ethernet networks." He advises companies to dedicate a separate network for storage-related traffic. In addition, the individuals supporting these networks will need to ramp up their storage-specific knowledge.

To manage next-generation iSCSI-based storage networks, organizations need individuals with diverse skill sets. Not only will these individuals need a thorough understanding of current networking disciplines such as routing, quality of service, security and performance management, but an understanding of storage disciplines as well, such as volume and LUN management, virtualization, storage classes and backup and recovery. Storage consultant, Jon William Toigo, says he can count on one hand the number of individuals he knows possessing both of these skill sets.

This dilemma may help explain why so few storage vendors and no tape library vendors currently support the iSCSI standard (see "Who supports iSCSI?," below). However, it's just a matter of time until storage vendors will support iSCSI. Customer demand continues to grow, according to Glenn Clowney, director of strategic marketing for the storage network group at Milpitas, CA-based Adaptec. He reports that many of the major storage vendors have done their internal iSCSI analysis and are starting to deploy the technology in their respective storage devices.

Who supports iSCSI?
Operating systems Microsoft has formally announced plans to support the iSCSI standard and will begin offering it as free download to Windows 2000 servers and clients and XP clients beginning in June 2003. Vendors such as Cisco, DataCore, FalconStor, IBM, Network Appliance, and others offer their own third-party iSCSI drivers that run under Windows, which allows Windows to run iSCSI. Linux currently offers various 2.1.x.x releases which implement iSCSI Draft 8 that works with existing iSCSI devices like the Cisco SN5400 series. The most current Linux 3.1.x.x releases implement iSCSI Draft 20. On the general Unix front, none of the major vendors have announced a native iSCSI driver for their respective flavors of Unix.

Switches Cisco, Hewlett-Packard, Nishan Systems, and Sanrad are among the vendors shipping products supporting iSCSI, while the major FC players such as Brocade, Inrange, and McData all have iSCSI in their roadmap. Until native OS iSCSI drivers are released and become generally available, third-party drivers need to be used.

Network cards Any existing network card will support any existing or new iSCSI driver. However, to gain full performance benefits offered by the recently ratified iSCSI standard, you'll need a special network card from a vendor such as Adaptec, Alacritech, Emulex, Intel, LSI Logic, or QLogic. These vendors currently offer cards that offload the processing of the TCP/IP stack from the server's CPU onto an application-specific integrated circuit (ASIC) located on the network card.

Storage arrays Network Appliance announced in February 2003 an iSCSI driver download for Windows that interoperates with its F800 and FAS900 series storage arrays. IBM currently ships its TotalStorage IP Storage 200i, which supports the Windows and Linux environments. EMC hasn't formally announced plans for the support of the iSCSI protocol in their current product lines, while Hitachi Data Systems forecasts iSCSI support for their Lightning line of products sometime in 2003. At least three vendors-- EqualLogic, Eurologic, and Huge Systems--are shipping iSCSI compliant storage arrays, while others such as 3PAR, BlueArc, and Raidzone all plan to bring products to market as soon as customer demand dictates.

Tape libraries Currently, Spectra Logic is the only tape vendor supporting iSCSI, though StorageTek forecasts support sometime in 2003. Most tape library vendors plan to take a wait-and-see approach and use some sort of an iSCSI bridge for connectivity. Atto Technology announced in March that its iPBridge 2500 C/D/R will enable iSCSI connectivity to SCSI tape drives.

Clowney sees Tier 1 vendors such as EMC and Hitachi Data Systems going slowly with iSCSI, fearing it will cannibalize their existing FC market. Meanwhile, other vendors such as Spectra Logic, Boulder, CO, and EqualLogic can be much more aggressive in this space because they want to support incremental growth without worrying about marginalizing an existing FC install base.

Bill Peldzus, senior storage consultant at GlassHouse Technologies, Framingham, MA, adds that neither Tier 1 nor Tier 2 storage vendors want to appear to their customers as having missed the iSCSI boat, so most are at least dipping their toe into the iSCSI waters.

One of the first big-name storage array vendors to take the iSCSI plunge is Network Appliance, Sunnyvale, CA. NetApp offers iSCSI support in its current F800 and FAS900 storage arrays, which can be obtained by upgrading its existing Ethernet interfaces to a free second protocol for existing customers on their support plan.

Dell will ship a storage array supporting iSCSI in the summer of 2003. An EMC spokesman said its customers aren't currently looking for iSCSI-enabled arrays. HDS forecasts an iSCSI announcement sometime in 2003 regarding their Lightning arrays. Smaller storage array vendors such as EqualLogic, Eurologic, and CA-based Huge Systems already natively support iSCSI in their arrays, while NAS vendors such as San Jose, CA-based BlueArc and 3PAR, Fremont, CA, are hedging their bets, introducing iSCSI products as soon as they see market demand.

Among the tape library vendors, none of them with the exception of Louisville, CO-based StorageTek expect support for iSCSI anytime soon. While StorageTek forecasts support for iSCSI sometime in 2003, the other tape library vendors anticipate using iSCSI bridges to connect existing tape drives to the emerging iSCSI storage networks until the market demand justifies the need to support it natively. Not missing a beat, Atto Technology, Amherst, NY, announced in March the release of the industry's first iSCSI bridge--the iPBridge 2500C/R/D. This device enables users to connect iSCSI network infrastructures to their current SCSI tape libraries, extending the functionality of tape libraries to iSCSI connected servers.

Where iSCSI fits
For organizations trying to figure out where iSCSI fits on their technology roadmap, here are some logical places to start. Datalink's Robinson recommends starting with applications and solutions where performance isn't an issue now, and won't be if redeployed with iSCSI. Almost invariably the question of performance crops up in terms of what happens when iSCSI runs over IP on an existing Ethernet network card. (See "The iSCSI performance impact," above)

Despite iSCSI's relative newness, Datalink recently completed a couple of pre-IETF standard iSCSI implementations in campus environments using the Cisco SN 5400 line of storage routers and Cisco's associated OS iSCSI drivers. Robinson says the cost savings these organizations experience using Ethernet based iSCSI vs. FC-based SCSI were significant. In the solutions where Datalink has deployed iSCSI using standard NICs, they have found tape backups perform well and run at approximately 70% to 80% of 1Gb FC.

Bryce Mackin, the marketing coordinator for the Storage Networking Industry Association (SNIA) IP storage forum, says it's important to remember that iSCSI's intended audience is small to midsize companies. Always trying to steer a diplomatic course between competing storage industry camps, SNIA views FC and iSCSI as complementary--not competing--technologies. Each, Mackin says, will have strong value propositions for different size organizations.

Storage consultant Toigo sees a lot of value in putting iSCSI networks behind NAS heads. In NAS environments, he says, performance isn't usually the primary concern and by putting NAS heads in front of iSCSI-based SANs is an economical and potentially highly scalable NAS solution. It also mitigates some of the storage and security management issues introduced in multiOS environments.

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?
A common question among users looking to deploy iSCSI is: Can they use the storage infrastructure they already own? The short answer is yes--the first generation of bridges and routers allow users to connect their new iSCSI devices with the storage hardware they already own.
Atto Technology offers the iPBridge 2500C/R/D that has 2 GbE ports which bridges to two Ultra160 SCSI ports. This device is aimed specifically for organizations looking to economically connect their existing high speed SCSI tape drives with their new iSCSI infrastructure to speed up their backup process.
Cisco Systems has had an entry in the iSCSI market for quite some time with their SN5400 line of storage routers. The SN 5420 offers a GbE port and one Fibre Channel (FC) port, which the SN 5428 offers 2GbE ports and eight FC ports. Cisco currently requires the deployment of their iSCSI drivers on the server operating systems in order for them to communicate with these devices. However, Cisco offers iSCSI drivers for a wide range of operating systems including Windows, Solaris, HP-UX, AIX, and Red Hat Linux and also includes advanced storage management functions such as LUN mapping, QoS and the ability to boot from the network.
Crossroads Systems recently introduced the Crossroads 10000 Storage Router. This particular router offers Fibre Channel, SCSI, iSCSI and InfiniBand connectivity options. In addition to the ability to connect to existing tape drives and storage arrays, it also offers built in storage management capabilities such as LUN mapping and masking down to the device level.

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.

Article 12 of 18

Dig Deeper on SAN technology and arrays

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

Get More Storage

Access to all of our back issues View All