Because of the success and widespread adoption of Fibre Channel, iSCSI technology is often overlooked. But with 10 Gigabit Ethernet and data center bridging technology picking up steam, the gap between iSCSI and Fibre Channel is closing, making iSCSI a more viable alternative for handling Ethernet storage. In this SearchStorage.com podcast, Demartek president Dennis Martin discusses some of the latest technologies affecting iSCSI performance, including data center bridging, iSCSI multipathing, CHAP and IPsec security, iSCSI offload adapters and jumbo frames. Listen to the podcast or read the transcript below to get more insights from Martin.
How can data center bridging improve iSCSI performance?
Dennis Martin: Data center bridging is an extension, or a collection of extensions, of Ethernet that basically gives it some lossless characteristics. ISCSI can run over this lossless form of Ethernet, and because Ethernet provides a reliable connection, the performance of iSCSI is improved.
There's a lot of talk about having to choose between iSCSI and Fibre Channel. What advantages does iSCSI have over Fibre Channel?
Martin: There are iSCSI initiators and even iSCSI targets included in some of the operating systems, so you can [choose iSCSI] in software relatively easily and you don't have to buy a lot of extra stuff. Certainly, if you're running 1-gig Ethernet, iSCSI can run over that; 1-gig Ethernet isn't very expensive, and a lot of people already have it, which is the advantage iSCSI has over Fibre Channel.
What about the disadvantages?
Martin: ISCSI tends to be a little bit higher in latency and very big shops already have Fibre Channel, so it's well established. The reliability and performance of Fibre Channel also tends to be a little bit better than iSCSI. Fibre Channel has been running over a lossless connection for years, so when you want high reliability and low latency, typically, you'd choose Fibre Channel.
What kinds of applications are better served with iSCSI than Fibre Channel?
Martin: It turns out that applications don't know the difference between iSCSI and Fibre Channel. Since they can't tell the difference, the best thing to do is figure out what you need. If you need very little latency, and lots of scalability and nodes in the network, you might go with Fibre Channel. If you don't need the low latency and need something a little simpler, then you could go with iSCSI. But again, the applications can't tell the difference.
How difficult is it to manage iSCSI multipathing, and are there any tools out there that can make it easier?
Martin: There are tools available. Most operating systems can handle multipath I/O (MPIO). Microsoft is MPIO, and there's MPxIO [the name of the MPIO function in Solaris], but in either case there's sort of generic multipathing that uses a single iSCSI session and you can have multiple addresses on the initiator, the target or both. That comes with the OS and is fairly straightforward. Some iSCSI targets support what's called multiple connections, so you can use a different sort of method to log in and then accomplish the multipathing using this multiple connection option. Typically, multiple connections and things like MPIO are mutually exclusive -- you have to pick one or the other. The fact that you can choose it is dependent on what the target supports.
Moving onto security, are the Challenge-Handshake Authentication Protocol (CHAP) and Internet Protocol Security (IPsec) the only two iSCSI security measures to know about or are there others?
Martin: CHAP and IPsec are the only iSCSI security measures I know of, and they can certainly handle a lot of things within iSCSI itself. You can also do other forms of encryption with the Ethernet connection. And there are other things you can do with data at rest and the storage side. There are a lot of other places you can do encryption, but CHAP and IPsec are the only ones I know of that are iSCSI-specific.
You tested iSCSI offload adapters in your 2011 iSCSI deployment guide. What kind of applications benefit from using this technology?
Martin: The principle of the iSCSI offload is that all of the iSCSI protocol and also the TCP/IP stack are offloaded to the card, into the adapter. It's for anything that needs a little bit tighter latency, but more importantly it drops the CPU utilization. Whenever you want to load up more things on your CPU, either more virtual machines, bigger applications or whatever, that would be the best benefit for using an iSCSI offload adapter.
What kind of advantages in iSCSI performance do you get from running jumbo frames? In what situations is it best to use them?
Martin: Jumbo frames give you more payload per transmission. Typically, jumbo frames run about 9,000 bytes, give or take a little bit for the headers, but 9,000 bytes is the most common. If you're running 10 GbE, a lot of the 10 GbE equipment defaults to jumbo frames, so you sort of get that for free. When you run it on 1 GbE, you do see a performance bump -- we've seen 10%, 20% and maybe more. If you want to get less congestion on the network, you use the bigger packets.
What are some best practices for handling iSCSI traffic?
Martin: Although iSCSI runs on Ethernet and pretty much everyone has Ethernet, the best practice is to run your iSCSI traffic on a separate network or at least a separate virtual LAN. That's because iSCSI puts a different kind of a traffic load on there. It's just better to keep iSCSI traffic separate because you don't want it to make more collisions on your regular network than you already have.
At the 1 GbE level, you can use separate network interface cards [NICs]. If you go to 10 GbE, you don't have to break it up quite as much because it’s a much bigger pipe. Certainly, you should use server-class network adapters for iSCSI. Don't try desktop NICs just because they're cheaper; they can't handle all the extra features iSCSI would like to use, including Receive-Side Scaling (RSS), partial offload functions like TCP and UDP checksum offload, Large Send Offload (LSO) and Large Receive Offload. It's not quite the full iSCSI, but there are some TCP offload subfunctions you can get, so you want to have an adapter that can do all that.
If you're concerned about security on the network, you certainly want to use CHAP, either one-way or mutual. And you want to use nonblocking switches. There are always a few other things you can do, like use MPIO, which we talked about already. If you're in an enterprise environment, you want to go high availability, so you have redundant adapters and that sort of thing if you want to get to the higher end.
This was first published in November 2012