Storage Basics: Is IP Storage Viable?

The media loves iSCSI: it is inexpensive to implement and offers many advantages over DAS or NAS solutions. Instead of focusing on how iSCSI works, this Storage Basics article will delve into some of the prevailing myths of IP storage. After understanding the important aspects of Fibre Channel and iSCSI technologies, we will be better positioned to make purchasing decisions.

Proponents of iSCSI are quick to point out some attractive facts. These consist of, but are not limited to:

• iSCSI is cheaper because it uses your existing IP infrastructure
• iSCSI is simpler to deploy
• iSCSI is “faster” because you can use 10GbE

These things are true, to varying degrees, depending on the environment and performance needs. Unfortunately, iSCSI cannot meet high-demand enterprise needs.

Performance

Let us first address performance. The truth is that iSCSI is certainly capable of some impressive throughput. Most any protocol, standard, or device can perform really well in a few niche applications, and iSCSI does excel in a few areas.

It is no mystery that iSCSI-only devices are targeted at the SMB market. Nobody is claiming you’re supposed to put huge transactional databases on iSCSI storage, but the proliferation of iSCSI hype has led to this cost-saving conclusion for many IT managers. Be extremely careful to avoid this trap.

For many reasons, Fibre Channel (FC) offers better performance. We often relegate the performance discussion to factors that do not accurately isolate the things being compared. Frequently we see arguments about iSCSI performance turn in to a discussion about how horrible SATAis, simply because many SATA array vendors offer iSCSI support. Yes, SATA will crumble under a load with lots of random IO, but it has nothing to do with the underlying access protocols.

FC is designed for large block IO and, as such, is heavily optimized to pass storage data around. Ethernet is not, but using jumbo frames (9K instead of 1.5K data units) can alleviate this concern a bit. FC HBA cards are, however, more efficient than Ethernet cards. Without getting into too much detail, FC essentially requires less CPU overhead because Ethernet usage requires an interrupt for each frame. Ethernet is really designed for small and frequent packet handling, not large data streams. iSCSI also rides on top of TCP, so traffic needs to be passed through many more layers in the OS before actually being sent out on the wire, further increasing latency. TCP checksum offload engines exist, so we exclude the added TCP overhead for practical purposes. In short, FC provides far less latency, and far better throughput. Again, deciding on an FC-based SAN versus iSCSI depends on the specific performance needs that you are addressing.

Network utilization is another important concern. A primary selling point of iSCSI is that you can utilize your existing network infrastructure; in fact, you can use the same NIC that other IP traffic passes on. This is fine for casual uses, but high-traffic (in the TCP/IP sense) servers that also need decent storage access times will clearly suffer with iSCSI deployed over a single network interface. In fact, iSCSI users often find, because they don’t really need good performance, that NAS-based solutions (i.e., mounting an NFS or CIFS share) would have worked just as well.

Options exist to help alleviate network congestion at the host. Obviously we can deploy a second network card, and luckily most servers these days ship with two to four Gb network interfaces. When we start talking about the need for 10GbE, we’re likely going to be running into other performance issues as outlined above. Assuming the access characteristics are ideally suited for iSCSI, the 10GbE option does exist.

How will a network handle 10GbE, though? Likely we’d need to upgrade some infrastructure to make this happen. Network congestion in IP storage networks often demands the separation of duties — a completely separate IP network for storage. People might be inclined to directly connect an Ethernet cable to their storage device if 10GbE would put too much strain on the network and there was only one server that needed the performance boost. Unfortunately, that devolves your situation back to DAS (direct-attached storage) days, and truth be told, a DAS setup could provide much better performance anyway.

Resiliency

The FC world is used to high availability configurations. Each node connecting to a SAN may use two HBA ports and “see” each storage LUNtwice, but over multiple paths. When configured correctly, these LUNs are accessed from a virtual LUN, and the driver transparently fails over between the actual LUNs in the event of an outage. This is how SAN storage is done, and everyone loves it.

In an FC SAN, we can upgrade or replace storage device controllers and switches with zero downtime. In the iSCSI world, we cannot. Each host is directly connected to a single switch, regardless of whether or not they share the same NIC with TCP/IP traffic. If that switch disappears, there is no failover capability. Some vendors have likely implemented proprietary multipathing solutions for iSCSI, but it is surely only going to work with only one operating system and their own storage device.

The good news in all of this drudgery is that you don’t really have to choose one technology over the other.

I urge everyone to consider iSCSI as an intermediary between high-performance FC-based SAN and file shares (NAS). Most FC storage array vendors now offer iSCSI support directly on the array itself, enabling businesses to use a hybrid deployment methodology. Your SAN-attached disk array can now be IP-attached and serve two distinct demands based on performance and reliability needs.

Don’t dismiss iSCSI because of the naysayers, and don’t adopt it without careful consideration.

Article courtesy of Enterprise Networking Planet