Upcoming Events

Cloud Connect
Santa Clara
Feb 13-16, 2012

Cloud Connect brings together the entire cloud eco-system to better understand the transformation we're experiencing and promises to be the defining event of the cloud computing industry. Learn about the latest cloud technologies and platforms from thought leaders in Cloud Connect’s comprehensive conference.

Register Now!

More Events »

Subscribe to Newsletter

  • Keep up with all of the latest news and analysis on the fast-moving IT industry with Network Computing newsletters.
Sign Up
Storage & Server Technology
R E V I E W  
Don't Sink Your IP SAN

  May 15, 2003
  By Steven Schuchart Jr.


TOC Issue TOC
Printer Print full article
Printer Print this page
Printer Download as PDF
E-Mail E-Mail this URL
Discuss Discuss this article
flame author Flame the author
 
  In this article
arrow
Introduction
arrow
Products Reviewed
arrow
Executive Summary
arrow
How We Tested
arrow
Online Only: Multiple Target Woes
arrow
Report Card

We know how Noah felt. Back in 2001 we forecast that Internet SCSI would change the storage landscape as we know it, but until lately iSCSI products came at a mere trickle. Still, we prepared--not by hammering together a boat, but by devising a plan to put iSCSI adapters through their paces. Now that the spec is finalized and the product stream is quickening, we feel, well, vindicated. And we won't have to share a cabin with skunks.

Taking a Performance Hit

Although iSCSI encapsulates standard SCSI commands for use over IP networks--including the Internet--storage applications impose unique requirements on the transport layer: All SCSI data must arrive in order; SCSI is sensitive to latency; and though iSCSI runs on TCP, SCSI is not tolerant of lost data packets/frames.

The IETF's iSCSI specification (RFC 3347) addresses these issues while ensuring that nothing done for iSCSI affects the base SCSI protocol, but the reality is that encapsulation of SCSI into TCP/IP packets is extremely CPU-intensive. That's because the TCP stack process is handled by the CPU, so the added iSCSI load lands a big performance hit. For example, our tests with a standard NIC showed a 30 percent CPU utilization on the standard read test. A Fibre Channel HBA (host bus adapter) running at 1 Gbps takes only about 2.1 percent CPU utilization. Clearly, this is a significant gap that can affect older servers particularly, possibly negating some of the cost savings that give iSCSI its edge over Fibre Channel.


You can tackle the CPU utilization problem a couple of ways. As always, there's the classic brute-force method: Servers with more horsepower have more CPU headroom and therefore are less affected by iSCSI. Simple, but expensive.



Maximum I/O 512-bpm Sequential Read

click to enlarge

Our suggestion: Hardware, baby. Fibre Channel HBAs handle the FC protocol; likewise, to get the most out of your iSCSI-connected servers, you'll need a specialized adapter that will rein in CPU utilization.

These devices work in two ways. Some off-load the TCP stack onto hardware, relieving the system CPU of that burden. Adapters using this method are called TOE (TCP Offload Engine) cards, and they look like any other NIC to the operating system, though you have to add an external iSCSI initiator--the software drivers that make iSCSI work. Microsoft is slated to have one available next month.

The second method is similar in approach to the TOE card, but with a twist: iSCSI HBAs appear to the operating system to be SCSI cards, and they come with their own iSCSI initiators--in iSCSI parlance, the "iSCSI driver."

For our tests, we gathered iSCSI adapters from Adaptec, Alacritech and Intel Corp. in our Green Bay, Wis., Real-World Labs®. Invitations went to Emulex Corp. and QLogic Corp. as well, but iSCSI products from those companies were not ready in time for our test window.

We tested two iSCSI HBAs, the Adaptec iSCSI Adapter 7211C card and the Intel Pro/1000 T IP Storage Adapter, and one TOE card, the Alacritech 1001x1 Copper Single-Port Server and Storage Accelerator (we pity the advertising agency that has to come up with a catchy jingle for that).

Our test setup used a Cisco 9216 Fibre Channel switch with an iSCSI blade, a Nishan 3000 Series Storage Switch, a Cisco Catalyst 3550 Gigabit Ethernet switch, and a Eurologic SANbloc 2 Fibre Channel RAID enclosure with 14 73-GB drives. The cards were tested in three identical Dell 2650 2U servers with 1 GB of memory and two 2.6-GHz Pentium 4 processors.

Overall, we found these products a little raw. For example, many ease-of-use and convenience features are missing. Command-line implementations are common. But after talking with vendors, we believe that many of these early look-and-feel issues will soon be resolved. Moreover, even without management bells and whistles, iSCSI is not terribly hard to use.

Our individual results were interesting, to say the least. The Alacritech card performed well in every test--provided it had two targets (see "Multiple Target Woes"). But its overall CPU utilization was a bit higher than that of its rivals. The Adaptec card, meanwhile, didn't function as well in throughput or read tests, but it turned in a strong overall performance, with ry good CPU-utilization numbers. For its part, the Intel Pro/1000 T IP Storage Adapter did well in most tests and aced CPU utilization, but it has performance issues with reading, regardless of the number of targets.

The wild card was our NWC Custom test, which we designed to simulate real-world access patterns. The Adaptec iSCSI-7211C scored very well in this test and was simply the most consistent card in performance, posting CPU utilization scores that won outright or came very close in every test. Throw in a very competitive price (all pricing is MSRP) and you have an Editor's Choice award winner.


start top Introduction Products Reviewed 

Research and Reports

Hypervisor Derby
August 2011

Network Computing: August 2011

TechWeb Careers