The IP SAN waiting game

analysis
Aug 6, 20044 mins

iSCSI, you SCSI -- we all scream for iSCSI hardware

“Ah, don’t worry about storage; storage is cheap.” I hear that little myth every time we purchase a new server setup. In a small way it’s true — per-gigabyte disk costs have dropped markedly in the past few years. Heck, if you add up all the hard disks at my house alone, I’m running more than 1TB with almost one-third of that running in a single machine.

Then again, I’m a geek carrying fetish-like obsessions for home-cooked DVR libraries, pointlessly vast MP3 collections, and gargantuan games that seem to be grabbing gigabytes of disk space with every install. For this, storage really is cheap.

But that’s not why we buy servers, and it’s certainly not why we deploy SANs. Storage area networks not only provide security, but ease management staffing burdens as well — and, most importantly, they keep critical data safe and constantly available. Your disk/gigabyte cost is often the least of your budgetary concerns when configuring a SAN.

All these factors combine to make buying enterprise storage far more complex, and therefore far more expensive, than slapping a couple of 200GB SATA drives in your kid’s game box.

Fortunately, Microsoft-based networks have some new choices opening up in this area. IP SANs are the current golden children of storage networking. By running a SAN on standard gigabit Ethernet media, network administrators can build a high-performance SAN segment without much need for specialized media hardware or consultants (read: Fibre Channel).

Next to its capability of using TCP/IP, an iSCSI array has a number of obvious benefits, the first being raw hardware cost. Not only are the disks reasonably priced, but allowing the SAN to run on standard Ethernet is cheaper all around, often saving as much as 50 percent compared with an FC-based system.

Another iSCSI plus vs. competing SAN architectures is distance. Optical SAN technologies can be severely limited in this category, but because iSCSI SANs use TCP/IP, they can manage vast quantities of storage traffic across equally vast distances. For example, in the New York area, there are several installations running networking across the Hudson River. With companies such as MCI dropping WAN pipe rates to as low as $130 per month for a full T1 line or just $2,500 for a metro-area Ethernet line, managing a long-distance or metro-area SAN architecture across TCP/IP is an obvious choice.

So what’s lacking? Well, iSCSI hardware for one. Microsoft announced its client-side iSCSI initiator more than a year ago. And in that time, Redmond has signed off on only about a dozen iSCSI-based hardware products. That’s not a long buyers’ guide from which to choose if building such a system is critical to your organization.

Now, however, Microsoft admins have the ability to take matters into their own hands and simply roll their own — which is something most of us have been wanting for some time anyway. After all, what’s the point in using an open standard such as TCP/IP if you can’t keep hardware-level control?

Recently, a number of third-party storage management software vendors announced products capable of managing generic iSCSI-based IP SANs and NAS setups. FalconStor Software has the aptly named iSCSI Storage Server package and String Bean Software has WinTarget.

FalconStor integrates with Windows Storage Server; administrators or storage solutions providers can use it easily to add iSCSI support to new products or existing SAN installations. String Bean operates similarly, but is seeing lots of action with Microsoft in conjunction with Microsoft’s new Virtual Machine technology.

There are other generic iSCSI software solutions out there if you want to stray off the Windows Storage Server platform — a choice not entirely out of the question for a back-end resource — or you can wait until EMC finally finishes its Celerra NS600 product. But for folks tired of waiting for iSCSI to come to them, FalconStor and String Bean allow them to simply go and grab what they need.